simon
2016-04-07 13:38
has joined #fabric-dev

simon
2016-04-07 13:38
@simon set the channel purpose: Design and development discussion for the fabric core

sheehan
2016-04-07 13:38
has joined #fabric-dev

tuand
2016-04-07 13:38
has joined #fabric-dev

jeffgarratt
2016-04-07 13:38
has joined #fabric-dev

muralisr
2016-04-07 13:38
has joined #fabric-dev

binhn
2016-04-07 13:38
has joined #fabric-dev

jyellick
2016-04-07 13:38
has joined #fabric-dev

kostas
2016-04-07 13:38
has joined #fabric-dev

richernandez
2016-04-07 14:16
has joined #fabric-dev

ethertyper
2016-04-07 14:24
has joined #fabric-dev

shemnon
2016-04-07 14:50
has joined #fabric-dev

zhipengh
2016-04-07 14:58
has joined #fabric-dev

simon
2016-04-07 15:34
: i'm adding an additional "persist" column to the rocksdb

simon
2016-04-07 15:35
this is mostly for per-node consensus state

simon
2016-04-07 15:35
just wanted to see whether anybody had input

simon
2016-04-07 15:35
in that process i'm making `db.get` public, and I'm adding `db.Set`

sheehan
2016-04-07 15:38
by column do you mean column family?

simon
2016-04-07 15:41
oh yes, sorry

simon
2016-04-07 15:42
i guess `Put` may be a better name? Get/Put, Get/Set

simon
2016-04-07 15:42
hm

sheehan
2016-04-07 15:43
are you naming the column family “persist"? Seems a bit vague. Other names are defined at https://github.com/hyperledger/fabric/blob/master/core/db/db.go#L36

simon
2016-04-07 15:44
yea

simon
2016-04-07 15:44
what suggestions do you have?

simon
2016-04-07 15:45
basically it is for in-memory state that should be persistent, so that the node appears as if it just was disconnected from the network

simon
2016-04-07 15:45
as opposed to having started from zero

sheehan
2016-04-07 15:46
ah, so you expect that others (in addition to consensus) may take advantage of the CF?

simon
2016-04-07 15:47
yes

simon
2016-04-07 15:47
no idea for what though

sheehan
2016-04-07 15:50
so maybe just a “consensus-persist” for now? Then you don’t have to be concerned with key collisions from others. I don’t think lots of CFs have any impact on RocksDB performance

georglink
2016-04-07 15:50
has joined #fabric-dev

simon
2016-04-07 15:50
yea, my idea was to use "consensus.foo" as key

simon
2016-04-07 15:51
it's just that adding additional CF is a bit awkward at the moment :simple_smile:

simon
2016-04-07 15:51
but sure

sheehan
2016-04-07 15:51
ah, ok. “persist” as a CF is fine with me also. Just throwing that out as a suggestion. I agree a single “persist” will be easier for others to take advantage of

simon
2016-04-07 15:51
we'll have to think about forward migration at some point

simon
2016-04-07 15:51
when our underlying database shape changes

simon
2016-04-07 15:52
also, we will have to think about disaster recovery

simon
2016-04-07 15:52
where a bug in the code renders the whole network unable to proceed or garbles some state

simon
2016-04-07 15:52
and manual operator intervention is needed

simon
2016-04-07 15:53
i.e. a way to manually update code and apply a "manually constructed" blockchain block/state delta

simon
2016-04-07 15:57
oh is jeff around?

simon
2016-04-07 15:57
i'd like to change the way messages are being passed through the system

simon
2016-04-07 15:58
right now the handlers form an open-coded linked list, which is not elegant

simon
2016-04-07 15:58
i'd prefer a message bus abstraction, where handlers register for message types

simon
2016-04-07 15:59
then main.go will become cleaner, because it doesn't have to use these handlerfactories

simon
2016-04-07 16:52
@sheehan: I'd like to change db_test.go to use a ioutil.TempDir() instead of peer.fileSystemPath

simon
2016-04-07 16:52
what do you think?

sheehan
2016-04-07 17:00
I have mixed feelings. I prefer the way it is now because I know exactly where the test db resides and I have full control if I need to change it. Is there a specific reason for wanting to use the tmp dir?

simon
2016-04-07 17:09
just so that somebody doing a go test doesn't need to have write access to /var

simon
2016-04-07 17:19
i don't quite understand the need for controlling where the testdb goes; it's just for a couple of unit tests

sheehan
2016-04-07 17:21
just preference for me. I’m ok with such a change, I understand your reasoning.

simon
2016-04-07 17:21
ok, thanks!

simon
2016-04-07 17:24
woops, one wrong git --reset, and a whole day's work gone

simon
2016-04-07 17:24
that'll teach me

simon
2016-04-07 17:26
ha, still in emacs undo history

simon
2016-04-07 17:26
yey emacs


sheehan
2016-04-07 17:55
speaking of git reset, I’m having trouble discarding compose-sieve.yml due to the different line feed characters. I know some others ran into this at the hackathon. Any hints? Tried `git reset —hard` with no luck


sheehan
2016-04-07 17:58
:simple_smile:

sheehan
2016-04-07 18:09
@simon: made a few comments on your persistence code. Looks good! Thanks for diving into the DB code

sheehan
2016-04-07 18:18
@binhn was able to help with my discard issue. The solution was git fetch upstream git checkout master git reset --hard upstream/master git push origin master --force

evan.wagner
2016-04-07 20:08
has joined #fabric-dev

gengjh
2016-04-08 00:12
has joined #fabric-dev

rgupta1
2016-04-08 00:33
has joined #fabric-dev

dileban
2016-04-08 00:39
has joined #fabric-dev

nick
2016-04-08 03:01
has joined #fabric-dev

simon
2016-04-08 13:51
sheehan: would you have some time to talk about the db module?

simon
2016-04-08 13:52
right now there is some abstraction (getters), but no setters

simon
2016-04-08 13:53
and we're using a singleton DB - makes me wonder whether we should just use getters/setters on the module, instead of on the db singleton object, and do away with `db.GetDBHandle()`

simon
2016-04-08 13:53
and say something like, `db.Get(db.BlockCF, key)`

simon
2016-04-08 13:54
and have `db.PutBatch(db.BlockCF, kvlist)`

sheehan
2016-04-08 15:02
@simon: busy right now, will respond in a bit. @manish-sethi may be able to discuss this topic with you now

manish-sethi
2016-04-08 15:02
has joined #fabric-dev

simon
2016-04-08 15:02
np

simon
2016-04-08 15:02
hi manish

manish-sethi
2016-04-08 15:03
Hi Simon

manish-sethi
2016-04-08 15:15
Previously, at some point, there was a talk about multiple chains and we were not sure about how we would be organising it in db (single v/s multiple.)…

simon
2016-04-08 15:15
i see

simon
2016-04-08 15:27
@manish-sethi: what about `db.GetDBHandle().Get(db.BlockCF, key)`, instead of `db.GetDBHandle().GetFromBlockCF(key)`?

stan.liberman
2016-04-08 15:29
has joined #fabric-dev

manish-sethi
2016-04-08 15:32
@simon - there is one such method in db and `GetFromBlockCF ` method is a higher level. For instance, `GetFromBlockCF ` actually calls `get(openchainDB.BlockchainCF, key)`.

manish-sethi
2016-04-08 15:35
@simon, I need to drop now. Let me know if you have more questions… I’ll answer later sometime.

simon
2016-04-08 15:35
i know that this function exists - i'm just talking about cleaning up that interface

toddsjsimmer
2016-04-08 16:57
has joined #fabric-dev

novusopt
2016-04-08 17:06
has joined #fabric-dev

keoja
2016-04-08 17:08
has joined #fabric-dev

stefan.teis
2016-04-09 11:02
has joined #fabric-dev

arnaud
2016-04-09 18:19
has joined #fabric-dev

noam
2016-04-10 10:19
has joined #fabric-dev

paulojrmoreira
2016-04-10 21:53
has joined #fabric-dev

tim.blankers
2016-04-11 07:12
has joined #fabric-dev

simon
2016-04-11 15:29
yesterday I thought about the block chain, and the data structure currently does not prove itself

simon
2016-04-11 15:31
I think it would be good if we could include cryptographic signatures of a quorum of validators with the block

simon
2016-04-11 15:31
that way the blockchain proves itself by means of the signatures

simon
2016-04-11 15:32
instead of having to ask a quorum of the validators for their view about the blockchain

jyellick
2016-04-11 15:34
Yes, we discussed this with Elli while she visited, I think this is a good idea, though ultimately with the validator model we should be storing the validator signatures which I think should accomplish this too?

simon
2016-04-11 15:35
you mean the endorser model?

jyellick
2016-04-11 15:38
Yes, sorry

simon
2016-04-11 15:38
but endorsers will only endorse single transactions?

simon
2016-04-11 15:38
unless we change how blocks are formed in that model

simon
2016-04-11 15:39
in any case, i think blocks should be signed cryptographically by the consensus network

simon
2016-04-11 15:39
in bitcoin, this would be a proof of work "signature", in pbft a quorum signature

sheehan
2016-04-11 15:41
The block contains `bytes consensusMetadata`. Is that what you plan to use or does the block structure need to be updated?

jyellick
2016-04-11 15:43
I believe `consensusMetadata` is included in the hash of the block, If we are signing the block hash, then we would have a problem, if we are signing some other subset of the block, then it could work, Simon?

jyellick
2016-04-11 15:44
(Or, we could of course remove `consensusMetadata` from the block hash)

simon
2016-04-11 15:44
yes

simon
2016-04-11 15:50
hmm

simon
2016-04-11 15:50
of course it would be nicer if these signatures were part of the block hash

simon
2016-04-11 15:50
but that's not going to work with pbft

jatinderbali
2016-04-11 17:12
has joined #fabric-dev

chetsky
2016-04-11 17:44
has joined #fabric-dev

keithsmith
2016-04-11 20:45
has joined #fabric-dev

akakoudakis
2016-04-11 22:00
has joined #fabric-dev

mcrafols
2016-04-12 07:42
has joined #fabric-dev

mandler
2016-04-13 08:29
has joined #fabric-dev

davidcosta
2016-04-14 09:19
has joined #fabric-dev

nickgaski
2016-04-14 13:58
has joined #fabric-dev

inabatk
2016-04-14 15:07
has joined #fabric-dev

christophera
2016-04-14 17:30
has joined #fabric-dev

michael
2016-04-14 17:51
has joined #fabric-dev

guruprasath
2016-04-14 18:33
has joined #fabric-dev

vipinb
2016-04-15 01:33
has joined #fabric-dev

gengjh
2016-04-15 01:42
In our dev env, we need a way to decode the content of the block/transaction and to make it human readable, is there any example to show us?

gengjh
2016-04-15 01:42
{ "nonHashData": { "localLedgerCommitTimestamp": { "nanos": 606964446, "seconds": 1459244499 } }, "previousBlockHash": "UZV+FhBHE02857iBf+OSIZaL2wBVJT6suBxDS1PFKSYAypSCHfgTyJSy49kfmYHqeCMX2JdtrZS4t5bVOjvGnA==", "stateHash": "t3IfS0OFK41CSCiwKYmvNzBtjdK494pfTK6r2Idp5g9FOljrWy+bl9x+JXhdHyILEvqMNjZPHWsna1K08iNNkA==", "transactions": [ { "cert": "MIIBxDCCAWqgAwIBAgIBATAKBggqhkjOPQQDAzApMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMQwwCgYDVQQDEwN0Y2EwHhcNMTYwMzI5MDkyNTQ1WhcNMTYwNjI3MDkyNTQ1WjAtMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMRAwDgYDVQQDDAdlc3NlX2lvMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXSHFowM9mBb+++b6iJ/6WOOivQn4X1poZq6o7eGgy72AAK8bicB2Bc3IVmmfXCY2k5E6FkGRkkn8mJz/YecmlqN/MH0wDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwDQYDVR0OBAYEBAECAwQwDwYDVR0jBAgwBoAEAQIDBDA9BgYqAwQFBgcBAf8EMC2cUEDeo6hqN7fCfHRbcxA0GpymnkNDqvNDAp1nmSSRwiqlwkfjaLPDpjf3D/8gbjAKBggqhkjOPQQDAwNIADBFAiAynxPnmqEOZ6fhcZy9TRIrUXUkEjDQyZFo08UtpWgqOAIhALcebR6xWZkYSZnBWqg2o5kVwZR6X5CcCKWx7t+s6XYw", "chaincodeID": "EoABMTU3NjQ4NjQxZjY0NDY1Y2U5NDZlNzM1YTA5MDk5MzFlZjE0ODNkYjUzNTk4MDE4NjRkMmViN2YyNDAwMzRmMGEzM2ZlMGFkYmJlYmM3OGFiODAyNzA5YjgzMmVkZmEzMTBjOWExZWNmYWQ5ZGVkYTUxNzlhNTFkZWJiNDdhZWI=", "payload": "CuoCCAESgwESgAExNTc2NDg2NDFmNjQ0NjVjZTk0NmU3MzVhMDkwOTkzMWVmMTQ4M2RiNTM1OTgwMTg2NGQyZWI3ZjI0MDAzNGYwYTMzZmUwYWRiYmViYzc4YWI4MDI3MDliODMyZWRmYTMxMGM5YTFlY2ZhZDlkZWRhNTE3OWE1MWRlYmI0N2FlYhrfAQoIcmVnaXN0ZXISQGI4ZGMyOThlODZhY2Y3NTQ1YTA4OGIxYThiZGE2MmNiNTE4NTQ2YTNjYjI0MzkxNWNlN2NiM2QxYzlhYTc1NzUSkAF7ImZpbGVuYW1lIjoiU2VuZCBzZWxlY3RlZCB0ZXh0IGluIGFuIE91dGxvb2sgbWVzc2FnZVxcc2NzLndvcmtmbG93LnppcCIsImZpbGV0eXBlIjoiYXBwbGljYXRpb24vemlwIiwibGFzdE1vZGlmaWVkIjoiMjAxNi0wMy0yOVQwOTo0MTozNi4wMDBaIn0=", "signature": "MEYCIQCliHCWbjyH+BgfQz6UXR0Ory5hlv8Jx8ZpY3j8VEtOFQIhALKc3Qo1TW1nJa2htJovSCiOjejBoP04zu/LDThIZQAd", "timestamp": { "nanos": 591012567, "seconds": 1459244499 }, "type": 3, "uuid": "cc36a4f9-925e-431d-8860-93e3e3bcbde9" } ] }

gengjh
2016-04-15 01:45
currently, the chaincodeID, payload of transactions are all encrypted

simon
2016-04-15 09:51
they're not encrypted, but encoded

simon
2016-04-15 09:51
unless you use confidentiality - then they are encrypted

gengjh
2016-04-15 10:06
@simon: do you know if we have example to decode or decrypt the above content?

jasmeet
2016-04-15 12:21
has joined #fabric-dev

simon
2016-04-15 12:23
gengjh: i don't think so - what do you want to get?

jasmeet
2016-04-15 12:29
Hi I just moved from IBM OBC to Hyperledger environmrent , having some difficulties while installing the setup . I building outside the vagrant environment . while running the setup.sh i got the following error cat: /etc/hyperledger-baseimage-release: no such file or directory . we are running this command inside cd opt/gopath/src/github.com/hyperledger/fabric/devenv#

simon
2016-04-15 12:32
yea i don't think the dev env (#) is made for baremetal use

jasmeet
2016-04-15 12:34
can u please elaborate

gengjh
2016-04-15 12:46
@simon: I want to understand what's in the payload of transaction for example. In some situations we need verify the content of the transaction is the expectation through rest api call in our test code. And in our poc, customer requests us to show the details info be recorded in the transaction.

simon
2016-04-15 12:49
you will have to use protobuf to pick apart the transaction payload

gengjh
2016-04-15 12:55
How about the encrypted transaction?

simon
2016-04-15 12:58
it is not encrypted

simon
2016-04-15 12:59
it's just base64 encoded

simon
2016-04-15 12:59
and inside is a protobuf transaction

gengjh
2016-04-15 13:03
Even if I enabled the security.privacy?

simon
2016-04-15 13:09
then it is probably encrypted

simon
2016-04-15 13:09
i don't know about encryption

simon
2016-04-15 13:09
i just looked at the transaction that you posted

gengjh
2016-04-15 13:15
ok, anyway, thanks for your info. will try to work on the decode first.

ghaskins
2016-04-15 17:06
has joined #fabric-dev

ajlopez
2016-04-15 22:06
has joined #fabric-dev

nathonline
2016-04-17 18:11
has joined #fabric-dev

mark.moir
2016-04-17 22:10
has joined #fabric-dev

yacovm
2016-04-18 14:17
has joined #fabric-dev

yacovm
2016-04-18 14:17
Hi. Has anyone encountered this { https://github.com/hyperledger/fabric/issues/802 } issue in the last days, or has any idea if anyone fixed it? I did a test in which I ran 3 validating peers with pbft consensus once with DEBUG level and once without and saw an expected behavior. I think it's not relevant anymore, can anyone disprove?

gennady.laventman
2016-04-18 14:25
has joined #fabric-dev

tuand
2016-04-18 14:40
@yavcom, can't comment on your exact question since i'm always running with log_level=debug but for pbft to work, you need a minimum of 4 peers

mcrafols
2016-04-18 14:41
that's if you want to tolerate one byzantine peer

mcrafols
2016-04-18 14:42
can't it run with 2 peers if f=0?

tuand
2016-04-18 14:43
it could but you're not taking advantage of pbft

mcrafols
2016-04-18 14:44
you need pbft anyway to reach consensus

yacovm
2016-04-18 14:46
I was just doing it for the sake of the test of the log level

yacovm
2016-04-18 14:47
in the issue they used pbft, so did I.

yacovm
2016-04-18 15:40
BTW, has anyone tried running 'behave -t "@issue_680" ' ? It fails on timeout, is that a known issue?

ghaskins
2016-04-18 15:40
@yacovm: that test fails on me near constantly, I think it is timing sensitive (and I have older machines)

sheehan
2016-04-18 15:48
For 680, also see https://github.com/hyperledger/fabric/issues/793#issuecomment-210861227. It doesn’t fail for me, but if anyone would like to submit a PR to increase the timeout it would be appreciated

john.crain
2016-04-19 01:03
has joined #fabric-dev

fjk
2016-04-19 05:52
has joined #fabric-dev

mcrafols
2016-04-19 10:05
hi I am trying to setup the Marbles app using a local blockchain network, and I am getting this error

mcrafols
2016-04-19 10:05
{ name: 'deploy() error', code: 400, details: { Error: 'Error getting chaincode package bytes: Error getting code G etting chaincode took too long' } }

mcrafols
2016-04-19 10:06
anybody knows what could be happening? Is there a wiki for the errors?

mcrafols
2016-04-19 10:58

mcrafols
2016-04-19 10:58
this is the error I get in the VP

gengjh
2016-04-19 12:38
Have you checked the log in the docker container which is used to run the chaincode?

mcrafols
2016-04-19 13:00
but the chaincode is not deployed yet

mcrafols
2016-04-19 13:03
besides, I am not sure how to see the log of the chaincode docker container

simon
2016-04-19 13:30
``` Then I wait up to "60" seconds for transaction to be committed to peers # steps/peer_basic_impl.py:315 60.403s | vp0 | vp1 | vp2 | Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/behave/model.py", line 1456, in run match.run(runner.context) File "/usr/lib/python2.7/site-packages/behave/model.py", line 1903, in run self.func(context, *args, **kwargs) File "steps/peer_basic_impl.py", line 349, in step_impl raise Exception("Max time exceeded waiting for transactions with current response map = {0}".format(respMap )) Exception: Max time exceeded waiting for transactions with current response map = {'bddtests_vp0_1': 404, 'bddt ests_vp1_1': 0, 'bddtests_vp2_1': 0} ```

simon
2016-04-19 13:30
what's going on with vp0?

tuand
2016-04-19 13:32
you've got the logs ? `behave -D logs=y` saves the container logs for any test that fails

tuand
2016-04-19 13:33
also, if you do `behave -n "some substring"` , that only runs tests which have the substring in their title

simon
2016-04-19 13:53
how long does a behave test run usually take?

tuand
2016-04-19 13:54
on my thinkpad W520/vagrant the full behave takes 8-10 minutes

simon
2016-04-19 13:54
okay, mine has been on much longer

simon
2016-04-19 13:59
35min :confused:

tuand
2016-04-19 14:11
you should have gotten all kinds of timeouts

tuand
2016-04-19 14:14
all the requests are set to timeout <60 seconds, will have to see where it's hanging

gongsu
2016-04-20 01:56
has joined #fabric-dev

fjk
2016-04-20 07:17
Can anyone here help me with a walk-through on setting up the hyperledger-fabric project on Ubuntu without vagrant? Currently struggling with a starting point for installation, would really appreciate your help.

ghaskins
2016-04-20 11:11
Suggest looking at devenv/setup.sh

ghaskins
2016-04-20 11:12
That's what vagrant runs. There is also some pointers in the doc for the baseimage components like rocksdb

ghaskins
2016-04-20 11:12
I'll find a link


ghaskins
2016-04-20 11:53
you might also find it useful to peruse the scripts in devenv/baseimage

simon
2016-04-20 13:46
i think i need to hack a tool that visualizes message flow events, so that i can debug the pbft code better

binhn
2016-04-20 14:03
with the Latest commit 488d266 issue #1131 — moving main.go to fabric/peer. You may encounter the problem in vagrant: ```vagrant@hyperledger-devenv:v0.0.9-2457c97:/opt/gopath/src/github.com/hyperledger/fabric$ cd peer/ -bash: cd: peer/: Not a directory``` It seems vagrant caches the `peer` exe file. The solution is to run: ```vagrant halt vagrant up ```

simon
2016-04-20 14:03
thanks for the heads up

tuand
2016-04-20 14:21
@simon what will this tool do ?

simon
2016-04-20 14:21
no idea - i just know that reading these text logs is very inefficient

simon
2016-04-20 14:22
there are tools that can show message sequence charts, but not with defined send/receive times

tuand
2016-04-20 14:25
absolutely agree about reading the logs ... would be nice though if i could restrict debug logging to just consensus. have you figured out the magic incantation for core.yaml ?

richernandez
2016-04-20 14:30
cat main.log | grep consensus?

richernandez
2016-04-20 14:31
or cat main.log | grep consensus > consensus.log

simon
2016-04-20 14:33
no, that's not the problem

simon
2016-04-20 14:33
the hundreds of prepare and commit messages interleaving each other is the difficulty

tuand
2016-04-20 14:33
yes, but we have bishop's logging mechanism defined in core.yaml which gives me tons of flexibility ... how do i set that up ?

simon
2016-04-20 14:34
maybe something that visualizes the state of all replicas wrt to current in-flight requests

tuand
2016-04-20 14:34
so simon, you want to be able to group all the activities by request

simon
2016-04-20 14:35
i don't know exactly what i want

simon
2016-04-20 14:35
:simple_smile:

tuand
2016-04-20 14:36
:innocent: i've heard of work going on with log analyzers, maybe that or some way we can use things like elasticsearch

ghaskins
2016-04-20 14:36
I wrote a data visualization tool a few years ago that might help, I should ask my employer if I can open source it

ghaskins
2016-04-20 14:37
but that said, I wonder if some of those logging tools like splunk might help

simon
2016-04-20 14:38
maybe

simon
2016-04-20 14:39
this is not to find http servers being slow

simon
2016-04-20 14:39
:simple_smile:

ghaskins
2016-04-20 14:47
i understand what you are interested in

ghaskins
2016-04-20 14:47
that is exactly what I built, just not for this purpose

ghaskins
2016-04-20 14:48
it did nanosecond level visualization of multiple contexts across a common time axis

ghaskins
2016-04-20 14:48
i suspect you are looking for something similar (albeit probably dont need ns resolution)

ghaskins
2016-04-20 14:49
just saying, there might be existing log visualization tools that get pretty close


csweir
2016-04-20 23:46
has joined #fabric-dev

nycnewman
2016-04-21 01:34
has joined #fabric-dev

fjk
2016-04-21 09:42
SSL read: error:00000000:lib(0):func(0):reason(0), errno 104 getting this error while setting the vagrant up

fjk
2016-04-21 09:43
can anyone help with this?

simon
2016-04-21 14:24
@jeffgarratt: i checked my performance branch again - seems that the second time I wrote it, I stuck to using streams for the devops requests

jeffgarratt
2016-04-21 14:25
@simon: did that prove faster than the GRPC RPC type?

simon
2016-04-21 14:25
I didn't check against RPC

jeffgarratt
2016-04-21 14:25
k

simon
2016-04-21 14:25
but it was easier to integrate

jeffgarratt
2016-04-21 14:26
understood

arnaud
2016-04-21 14:47
I recreated a dev-env from scratch with the latest code and behave reports 7 failed scenarios, is that expected?

arnaud
2016-04-21 14:47
it seems that some of this is known but where does one find that info (what results are expected)

tuand
2016-04-21 14:50
`behave` gives you a summary at the end. Should be 0 tests failed. There was a PR yesterday ( i think ) that took care of some timeouts

arnaud
2016-04-21 14:50
hmm, I got 7 fails

simon
2016-04-21 14:51
:smile:

tuand
2016-04-21 14:51
there's an open issue with some tests failing with `no route to host` which i can't remember the number for

simon
2016-04-21 14:51
i keep getting fails too

tuand
2016-04-21 14:51
ignore simon :smile:

simon
2016-04-21 14:51
but i have an ancient laptop

arnaud
2016-04-21 14:52
:simple_smile:

tuand
2016-04-21 14:52
what's the behave output say ?

arnaud
2016-04-21 14:52
what's ancient? that's on a w520

arnaud
2016-04-21 14:54
Failing scenarios: peer_basic.feature:437 chaincode example02 with 4 peers and 1 membersrvc, issue #567 -- @1.1 Consensus Options peer_basic.feature:439 chaincode example02 with 4 peers and 1 membersrvc, issue #567 -- @1.3 Consensus Options peer_basic.feature:522 chaincode example02 with 4 peers and 1 membersrvc, issue #680 (State transfer) -- @1.2 Consensus Options peer_basic.feature:651 4 peers and 1 membersrvc, consensus still works if one backup replica fails -- @1.2 Consensus Options peer_basic.feature:652 4 peers and 1 membersrvc, consensus still works if one backup replica fails -- @1.3 Consensus Options peer_basic.feature:713 4 peers and 1 membersrvc, consensus fails if 2 backup replicas fail -- @1.2 Consensus Options peer_basic.feature:806 chaincode example02 with 4 peers and 1 membersrvc, issue #1001 (Channel instead of Chat stream for transcation ingestion) -- @1.1 Consensus Options 0 features passed, 1 failed, 1 skipped 16 scenarios passed, 7 failed, 4 skipped 257 steps passed, 7 failed, 296 skipped, 0 undefined

tuand
2016-04-21 14:57
further up in the output ... it logs the actual error. try searching on the string `#567 -- @1.1` for example

arnaud
2016-04-21 15:01
is the behave output automatically saved somewhere or do I need to capture the output myself?

arnaud
2016-04-21 15:13
well, I just reran behave and only have 6 failed scenarios so this isn't reliable

arnaud
2016-04-21 15:14
here is the first error:

arnaud
2016-04-21 15:14
@issue_567 Scenario Outline: chaincode example02 with 4 peers and 1 membersrvc, issue #567 -- @1.1 Consensus Options # peer_basic.feature:437 Given we compose "docker-compose-4-consensus-noops.yml" # steps/peer_basic_impl.py:88 Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1456, in run match.run(runner.context) File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1903, in run self.func(context, *args, **kwargs) File "steps/peer_basic_impl.py", line 97, in step_impl bdd_test_util.cli_call(context, ["docker-compose", "-f", composeYamlFile, "up","--force-recreate", "-d"], expect_success=True) File "/opt/gopath/src/github.com/hyperledger/fabric/bddtests/steps/bdd_test_util.py", line 27, in cli_call raise subprocess.CalledProcessError(p.returncode, arg_list, output) CalledProcessError: Command '['docker-compose', '-f', u'docker-compose-4-consensus-noops.yml', 'up', '--force-recreate', '-d']' returned non-zero exit status 1 Captured stdout: Output: Error Message: Creating bddtests_membersrvc0_1 Creating bddtests_vp0_1 driver failed programming external connectivity on endpoint bddtests_vp0_1 (cf2ce98106ed1f478b3aa2199d2de9a2c19c855c668c5ad06d4489904151f16f): Error starting userland proxy: listen tcp 0.0.0.0:5000: bind: address already in use

sheehan
2016-04-21 15:50
@arnaud: make sure you don’t already have an example02 binary in the examples/chaincode/go/chaincode_example02 path. I’ve found that can cause problems

arnaud
2016-04-21 15:51
ah, good to know

arnaud
2016-04-21 15:51
nope, don't have that

arnaud
2016-04-21 15:52
I just built the whole thing from scratch, ran the unit tests - which passed - and then behave

arnaud
2016-04-21 15:52
so it should be a clean env

sheehan
2016-04-21 15:54
The behave tests currently pass for me on the master branch. Some people are seeing issues though. https://github.com/hyperledger/fabric/issues/1190. I can replicate this issue in one of the current PRs so I’m investigating. Looks different than what you’re seeing, but maybe related?

harshal
2016-04-21 16:27
has joined #fabric-dev

arnaud
2016-04-21 17:17
not sure, doesn't seem to be quite the same

sheehan
2016-04-21 17:22
@arnaud: do you have the peer running? The peer needs to be stopped while running the behave tests.

arnaud
2016-04-21 17:23
ah ah!

arnaud
2016-04-21 17:23
I sure do

arnaud
2016-04-21 17:23
let me kill it and try again

arnaud
2016-04-21 17:41
@sheehan: you're the man! 22 passed, I still have 1 failed but not so bad

arnaud
2016-04-21 17:41
we've got to update the instructions, I'll submit a PR

simon
2016-04-21 17:42
better yet, make it work with running peer

arnaud
2016-04-21 17:42
sure... that would be better indeed

sheehan
2016-04-21 18:05
there are some unit tests that actually run a peer and deploy chaincode. They were written before the behave tests existed. I’d support removing those as I feel they’ve been replaced by the behave tests and they’re somewhat fragile.

renat-altoros
2016-04-22 07:20
has joined #fabric-dev

jasmeet
2016-04-22 10:47
While running this step -Start up the peer node with no connections to a leader or validator as follows. cd /opt/gopath/src/github.com/openblockchain/obc-peer ./obc-peer peer Getting Error - Failed to listen: listen tcp 0.0.0.0:30303: bind: address already in use

muralisr
2016-04-22 10:52
@jasmeet: will be good to get on hyperledger… in any case it just means likely peer is running somewhere (unless you have another app using the port)

fjk
2016-04-22 11:10
Can anyone help me with an error which i'm facing while setting up the hyperledger environment on ubuntu 14.04LTS 4:05 SSL read: error:00000000:lib(0):func(0):reason(0), errno 104 --- Getting this error while setting the vagrant up

fjk
2016-04-22 11:20
that error seems resolved, have got a new one, There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["startvm", "f5a4f3a4-3089-4f1a-a170-8dcd67e3e5d5", "--type", "headless"] Stderr: VBoxManage: error: VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

srbamb
2016-04-22 11:21
has joined #fabric-dev

ghaskins
2016-04-22 11:40
@fjk: it sounds like you are trying to run vagrant from an environment that doesn't have VMX enabled. This can be for a few different reasons

ghaskins
2016-04-22 11:41
Are you running these commands from a VM per chance?

ghaskins
2016-04-22 11:41
If not, you might need to enable VMX in the bios

fjk
2016-04-22 11:42
@ghaskins: will try enabling the VMX

simon
2016-04-22 14:46
sheehan: do you know whether I can keep references to gorocksdb.Iterator.Value.Data() ([]byte)?

simon
2016-04-22 14:46
even after closing the iterator

simon
2016-04-22 14:46
or do I need to manually copy that slice

simon
2016-04-22 15:13
yes, i do

simon
2016-04-22 15:13
i consider that to be a bug in gorocksdb - can't introduce memory errors

sheehan
2016-04-22 15:19
correct, if it’s an iterator, you must copy as the slices will be freed when the iterator is closed. Outside of an iterator you need to be sure to call `slice.Free()`

simon
2016-04-22 15:22
that's bad that you can crash the instance if you access the slice data later

sheehan
2016-04-22 15:24
yes, that api should be hidden from almost everyone as it’s only exposed below the ledger. But I agree that it could be better designed

simon
2016-04-22 15:26
well, i consider that to be a rocksdb bug

joseph
2016-04-22 16:13
has joined #fabric-dev

latone
2016-04-24 00:40
has joined #fabric-dev

yacovm
2016-04-24 11:36
Hi. Does anyone know if there is some kind of secure signature on query results? How can a client validate that the results of a REST call has indeed gone through the consensus?

gennady.laventman
2016-04-24 12:03
@yacovm: Same question. Seconded.

muralisr
2016-04-24 12:13
@yacovm: currently query is only to the peer to which it is addressed.

yacovm
2016-04-24 12:47
@muralisr: yeah I know, but what I'm asking is- does the answering peer has any "proof" that the query went through consensus? I don't see such a thing in the REST doc on github

yacovm
2016-04-24 12:48
there is only a secureContext which doesn't prove that

muralisr
2016-04-24 12:51
@yacovm: the query - currently - does not go through consensus at all. It is directly responded to by the peer to which it is addressed.

yacovm
2016-04-24 12:58
yeah, you're right. I was under the impression that it behaves like doChainTransaction in helper/handler.go

yacovm
2016-04-24 12:58
thanks

muralisr
2016-04-24 12:59
sure thing

simon
2016-04-25 10:06
yacovm: are you asking about strong reads?

jasmeet
2016-04-25 10:07
default: SSH auth method: private key Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong. If you're using a custom box, make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well. If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value.

jasmeet
2016-04-25 10:08
command to increase increase/ the timeout ("config.vm.boot_timeout") value.

jasmeet
2016-04-25 10:10
@simon: any idea

simon
2016-04-25 10:10
nope, i don't use vagrant

jasmeet
2016-04-25 10:11
@simon: WHAT else are u using ?

simon
2016-04-25 10:11
i just run directly on my linux

yacovm
2016-04-25 10:20
@simon: no, I was wondering about reads that go to byzantine peers, the fact that we have byzantine consensus, but when a client performs a read that goes to a byzantine peer, it may return any values it wants, can't it?

simon
2016-04-25 10:20
the client asks its local trusted peer

simon
2016-04-25 10:21
i.e. the bank's server

yacovm
2016-04-25 10:21
oh, I see.

yacovm
2016-04-25 10:22
thanks

simon
2016-04-25 10:22
even if you did a strong read

simon
2016-04-25 10:22
how do you know that the machines signing the answer are legitimate?

yacovm
2016-04-25 10:22
a strong read you mean reading f+1 replicas?

simon
2016-04-25 10:22
yes

yacovm
2016-04-25 10:23
if you read f+1 replicas then you have at least 1 "correct" read

yacovm
2016-04-25 10:23
you might not know which one is that

simon
2016-04-25 10:23
yes, but how do you know which machines you should ask?

yacovm
2016-04-25 10:23
if you do "get peers" on the replica, for instance

yacovm
2016-04-25 10:24
on the local peer, that is

simon
2016-04-25 10:24
but then you trust the local peer

yacovm
2016-04-25 10:24
true, otherwise the local peer is also byzantine and returns to you many "fake" peers, etc. etc.

simon
2016-04-25 10:25
correct

wimtobback
2016-04-25 11:38
has joined #fabric-dev

simon
2016-04-25 11:53
```11:51:53.120 [crypto] Deploy -> INFO 0d7 Initializing client [binhn]... 11:51:53.600 [crypto] callTCACreateCertificateSet -> ERRO 0d8 [client.binhn] Failed requesting tca create certificate set [rpc error: code = 2 desc = "proto: bad wiretype for field protos.Signature.Type: got wiretype 2, want 0"]. 11:51:53.600 [crypto] Deploy -> INFO 0d9 Initializing client [binhn]...done! 11:51:53.600 [devops] Deploy -> DEBU 0da Creating secure transaction 5844bc142dcc9e788785e026e22c855957b2c754c912702c58d997dedbc9a042f05d152f6db0fbd7810d95c1b880c210566c9de3093aae0ab76ad2d90e9cfaa5 11:51:53.603 [crypto] callTCACreateCertificateSet -> ERRO 0db [client.binhn] Failed requesting tca create certificate set [rpc error: code = 2 desc = "proto: bad wiretype for field protos.Signature.Type: got wiretype 2, want 0"]. 11:51:53.603 [crypto] NewChaincodeDeployTransaction -> ERRO 0dc [client.binhn] Failed getting next transaction certificate [Failed loading TCerts from TCA]. 11:51:53.603 [crypto] CloseClient -> INFO 0dd Closing client [binhn]... 11:51:53.603 [rest] Deploy -> ERRO 0de {"Error": "Deploying Chaincode -- Failed loading TCerts from TCA"} ```

simon
2016-04-25 11:53
any ideas?

simon
2016-04-25 12:01
ah, i may have had to build a new obcca

simon
2016-04-25 15:43
sheehan: why doesn't `Block` contain the block number?

simon
2016-04-25 15:45
the fact that `ledger.GetBlock(ledger.GetBlockchainSize())` doesn't work is very confusing

simon
2016-04-25 15:45
we need to fix our numbering

simon
2016-04-25 15:45
i keep having off by one errors

sheehan
2016-04-25 15:49
I think we never had a use case for having the number in a block. Part of it is also likely historical as bitcoin does not have a number in a block. Not aware that `ledger.GetBlock(ledger.GetBlockchainSize())` is not working. Is there an open issue describing the problem?

simon
2016-04-25 15:53
well, because size() returns 1 if there is just a genesis block

simon
2016-04-25 15:54
and getblock takes block number, i.e. 0

simon
2016-04-25 15:54
i wanted to talk with you about this before opening an issue

sheehan
2016-04-25 15:57
it’s designed to behave like an array

simon
2016-04-25 15:58
yea i understand

simon
2016-04-25 15:58
still easy to make one off mistakes

simon
2016-04-25 15:59
maybe have a function relating to "head", "tip", etc.

simon
2016-04-25 16:00
well I just shipped a blockchaininfo over the network, and then tried to get the `info.Height` block, which of course failed

simon
2016-04-25 16:00
gave me a different block

simon
2016-04-25 16:02
sheehan: it's not the first time that I had to stop and think whether I had to subtract/add `1`, so it seems that the interface is not intuitive to me

simon
2016-04-25 16:03
ah, maybe something like `GetBlockByHeight`

sheehan
2016-04-25 16:03
sure, understand the confusion. open to updating the api so that’s it’s more clear

simon
2016-04-25 16:03
which then internally can subtract one

sheehan
2016-04-25 16:08
So have both `GetBlockByNumber` and `GetBlockByHeight`? I’m concerned that may be confusing also

simon
2016-04-25 16:09
oh

simon
2016-04-25 16:09
chuck the bynumber then

simon
2016-04-25 16:09
oh i don't know!

simon
2016-04-25 16:09
i'll think more about it

simon
2016-04-25 16:09
whatever makes all numbers the same :simple_smile:

simon
2016-04-25 17:27
could we get rid of the errors returned by GetLedger()?

simon
2016-04-25 17:27
under what situation would that even happen?


sheehan
2016-04-25 17:49
would happen if there was a IO error

simon
2016-04-25 17:55
right, but what then?

simon
2016-04-25 17:55
shouldn't we just panic and abort execution?

sheehan
2016-04-25 17:56
yeah, panic is likely the correct thing to do

simon
2016-04-25 17:57
that would clean up a lot of code

simon
2016-04-25 17:58
and also provide a better uniform way of dealing with such fatal errors

fabio
2016-04-25 20:54
has joined #fabric-dev

daniels
2016-04-26 09:46
has joined #fabric-dev

lfeagan
2016-04-27 12:37
has joined #fabric-dev

bcbrock
2016-04-27 15:40
has joined #fabric-dev

simon
2016-04-28 08:44
i could reproduce an issue with behave/#680/1.3 (like it keeps failing on CI)

simon
2016-04-28 08:44
but it is very odd

simon
2016-04-28 08:45
the state transfer successfully updates the blockchain (length changes correctly)

simon
2016-04-28 08:46
but later when the chaincode is launched, it seems to reply with the old state?

simon
2016-04-28 10:30
i just can't get it to fail locally

simon
2016-04-28 13:44
how do i get my PRs merged?

simon
2016-04-28 14:01
@muralisr, @jyellick: how do we tie in chaincode deploy and state transfer? Do we have to? Will chaincode be deployed (and killed?) automatically, based on updated world state?

jyellick
2016-04-28 14:04
@simon: @muralisr I thought the conclusion had been that chaincode needs to live in the state, not in the block, so that so long as our state is correct, we don't need the blockchain to redeploy chaincodes

arnaud
2016-04-28 17:54
What happened to behave?

arnaud
2016-04-28 17:55
behave is no longer in bddtests on master?

jeffgarratt
2016-04-28 19:19

arnaud
2016-04-28 19:25
got it, thanks

igor
2016-04-29 11:15
has joined #fabric-dev

takekiyokubo
2016-05-02 13:48
has joined #fabric-dev

ratnakar
2016-05-02 19:50
has joined #fabric-dev

suma
2016-05-02 21:14
has joined #fabric-dev

sheehan
2016-05-03 03:27
I’m done with PRs for the day. If I’ve added a note to your PR indicating a rebase on master is needed, please do so when you have a chance. thanks

cbf
2016-05-03 12:00
has joined #fabric-dev

hill
2016-05-04 14:31
has joined #fabric-dev

nishi
2016-05-04 17:02
has joined #fabric-dev

arnaud
2016-05-04 18:08
has anybody succeeded in getting [ci-skip] to work?

arnaud
2016-05-04 18:09
I keep trying but for some reason I haven't managed to get it right yet and travis kicks in every time :confused:

ghaskins
2016-05-04 18:14
I dont think its just you, i have witnessed a handful of PRs that had the flag set yet still had a travis cycle consumed

ghaskins
2016-05-04 18:14
so id guess its either not working right, or we have a user-education issue on how to properly format the tag

arnaud
2016-05-04 18:15
right

cbf
2016-05-04 18:54
[ci skip] does not appear to be working @ramesh is looking into this

posnerj
2016-05-04 19:14
has joined #fabric-dev

yacovm
2016-05-05 20:36
anyone alive? I just cloned the fabric and ran `go test http://github.com/hyperledger/fabric/core/peer`, and it failed with: 2016/05/05 20:35:20 setting Number of procs to -1, was 64 2016/05/05 20:35:21 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:30303: getsockopt: connection refused"; Reconnecting to "0.0.0.0:30303" 2016/05/05 20:35:22 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:30303: getsockopt: connection refused"; Reconnecting to "0.0.0.0:30303" error connection to server at host:port = 0.0.0.0:30303 FAIL http://github.com/hyperledger/fabric/core/peer 2.710s Also tried setting the peer.address from 0.0.0.0:30303 to my ip:30303 but also failed, can anyone help?

tuand
2016-05-05 20:41
you need to have a 2nd peer running before running the go test

yacovm
2016-05-05 20:42
doesn't the test do it itself?

tuand
2016-05-05 20:43
no ... the behave tests will spin up and delete peers as needed but you need to manually set things up for the unit tests

yacovm
2016-05-05 20:44
But, doesn't travis simply run the unit tests?

tuand
2016-05-05 20:45
travis runs both sets of tests ... i haven't looked at the travis scripts but i think one of the startup scripts will bring up a peer before executing go test

ghaskins
2016-05-05 20:45
travis will start the peer for you, yes

ghaskins
2016-05-05 20:45
if you run the tests locally, you have to start it manually (at least today)

yacovm
2016-05-05 20:46
where do I find the arguments/conf?

tuand
2016-05-05 20:46
install.md , section 3.1

yacovm
2016-05-05 20:46
thanks!

yacovm
2016-05-05 20:58
Actually, there is another thing I'd like to ask- I submitted a PR but Travis failed my build on the fabric/core/chaincode test (killed it, maybe due to timeout) but it passes on my machine, along with all the rest (now once I ran the peer externally)... I see that ghaskins's PR build also failed on the same thing it failed with my build. Is Travis tired or something?

ghaskins
2016-05-05 20:59
it seems like something is not well either with the unit-tests or travis’ execution of them

ghaskins
2016-05-05 20:59
though they run fine locally, so I suspect something up with travis

yacovm
2016-05-05 21:03
I see. BTW - do you know how can I emulate the travis build on my machine? I simply invoke serially the {before_}x{install, script} sections of the travis.yml?

ghaskins
2016-05-05 21:03
you can actually trigger it from your own github fork

yacovm
2016-05-05 21:03
but I don't have a travis server

ghaskins
2016-05-05 21:03
theres a PR with doc on how to do that, hold on

ghaskins
2016-05-05 21:03
i mean the public one

yacovm
2016-05-05 21:04
yeah but than it runs on github, I want to run it on my server (it'll be faster)


ghaskins
2016-05-05 21:04
oh, i see

ghaskins
2016-05-05 21:04
dont know how to do that

yacovm
2016-05-05 21:04
ok, in any case many thanks! I hope someone fixes the build

simon
2016-05-06 12:57
any idea what #1380 is about?

tuand
2016-05-06 13:01
is this the issue @ghaskins @sheehan @muralisr are discussing over in # ?

simon
2016-05-06 13:03
maybe

simon
2016-05-06 13:03
i think we should revert the commit in question

tuand
2016-05-06 13:10
agreed

simon
2016-05-06 13:11
who merged it anyways?

simon
2016-05-06 13:12
ah, greg is committer now

simon
2016-05-06 13:12
nice

muralisr
2016-05-06 13:26
@simon… will be fixing it shortly.

sheehan
2016-05-06 13:26
this was my fault. Apologies. Incident report We ran tests locally on Chris’s laptop and they passed. Not sure why yet. Then a PR was created with [ci-skip] because it was comments only I looked though it very carefully and confirmed only comments were changed so agreed that [ci-skip] was safe In the future, we should run test cases on ALL PRs that include any modification to .go files.

simon
2016-05-06 13:40
:simple_smile:

ghaskins
2016-05-06 13:41
If it makes you feel any better, they inexplicably pass when I run local too

ghaskins
2016-05-06 13:42
So it could have happened to anyone. I think your proposed policy makes sense though

ghaskins
2016-05-06 13:42
I tend to never start a peer with the unit tests, I bet that's why they passed

ghaskins
2016-05-06 13:43
Need to get out of that habit

simon
2016-05-06 13:43
the behave tests need to be sped up

simon
2016-05-06 13:43
does CI still build rocksdb?

ghaskins
2016-05-06 13:43
@yes, unfortunately

ghaskins
2016-05-06 13:44
Though that is only about 5m of the 50m it's taking

simon
2016-05-06 13:44
do we have a time breakdown?

ghaskins
2016-05-06 13:44
Sorry, @simon yes

ghaskins
2016-05-06 13:45
@ramesh might

ramesh
2016-05-06 13:45
has joined #fabric-dev

simon
2016-05-06 13:45
getting docker compose and the docker image take quite some time

simon
2016-05-06 13:45
so ideally we'd use caching

ghaskins
2016-05-06 13:46
Yeah, two options I can think of would be to run the tests within docker baseimage, or revisit PPA

ghaskins
2016-05-06 13:47
Stepping out for a few hours

michaelhaley
2016-05-06 13:48
has joined #fabric-dev

ramesh
2016-05-06 13:49
Travis doesn't support caching feature for trusty environments (Sudo Required)

simon
2016-05-06 13:52
aha!

juanblanco
2016-05-08 17:35
has joined #fabric-dev

pablofullana
2016-05-08 22:10
has joined #fabric-dev

shubhamvrkr
2016-05-09 06:26
has joined #fabric-dev

nits7sid
2016-05-09 06:26
has joined #fabric-dev

simon
2016-05-09 10:04
@muralisr: how do you suggest using system chaincode to store pbft configuration?

muralisr
2016-05-09 12:35
@simon The question to me is if we need a sys cc to store pbft config. If it is totally static and can never change, current yaml may be good enough ?

muralisr
2016-05-09 12:36
Otherwise the sys CC should have the same features as a regular chaincode as far as storage is concerned, ie, all the ledger state methods. The real thing to consider is that every “invoke” operation will be a transaction and so every change one makes to the state will be too. The last thing is you have query access which you may leverage to allow users to get information.

muralisr
2016-05-09 12:37
its somewhat curious that the changes that we will make for PBFT config itself has to go through consensus. Sounds there may be chicken-egg issues here

ghaskins
2016-05-09 12:38
@muralisr: I think its achievable, but it does require careful design

muralisr
2016-05-09 12:40
@ghaskins: it is.. really depends upon details of this cc

simon
2016-05-09 12:48
muralisr: no, it is not static (not necessarily), and all replicas need to use the same config

muralisr
2016-05-09 12:48
ok.

simon
2016-05-09 12:49
e.g. the set of validators

simon
2016-05-09 12:49
or the log/watermarks size that pbft uses

simon
2016-05-09 12:50
my idea was to store the original config in the genesis block, and change config through a system chaincode

muralisr
2016-05-09 13:15
I see. I thought these are properties are “hard to change” to say the least.

simon
2016-05-09 13:32
yes, so they definitely shouldn't be in a random yaml file that everybody can edit

ranga
2016-05-09 15:43
has joined #fabric-dev

ghaskins
2016-05-09 15:58

ghaskins
2016-05-09 16:04
Not to be pushy, I just have a few follow-on patches to do, but won’t base on top of this if its not likely to be accepted

jyellick
2016-05-09 16:58
When I try to run the unit tests locally, I'm getting an OOM problem with the current master: ``` 2016/05/09 16:54:47 Computing crypto-hash for bucket [level=[0], bucketNumber=[1]] by merging [3] children 2016/05/09 16:54:47 Constructing bucket-cache with max bucket cache size = [100] MBs 2016/05/09 16:54:47 Loaded buckets data in cache. Total buckets in DB = [44]. Total cache size:=6400 fatal error: runtime: out of memory ``` I've bumped my Vagrant up to 8GB, to no effect. I was looking back through the README to see if the test invocations have changed, but they seem to be gone from the doc, anyone know what's going on?

jyellick
2016-05-09 16:59
@ghaskins: @sheehan ^^

tuand
2016-05-09 17:00
check in install.md ?

sheehan
2016-05-09 17:02
how big is your DB?

sheehan
2016-05-09 17:02
under /var/hyperledger/

jyellick
2016-05-09 17:02
15GB, looks like

sheehan
2016-05-09 17:02
hmm, maybe compress that and put it off to the side somewhere?

sheehan
2016-05-09 17:03
may be useful for testing

sheehan
2016-05-09 17:03
@ghaskins: I intend to look at you make changes today

jyellick
2016-05-09 17:04
@sheehan: Sure, I'll pull it off, then delete it and you think that ought to fix things?

ghaskins
2016-05-09 17:09
@jyellick: ive not seen that, but I tend to be operating with clean-slates each iteration. Am I understanding correctly that you are running an existing database?

ghaskins
2016-05-09 17:10
or is 15G typical for a clean-slate run (ive never looked)

jyellick
2016-05-09 17:11
@ghaskins: I'm not intentionally doing anything, but I have not destroyed my dev env in a week or two, so there is a good chance the DB has grown

sheehan
2016-05-09 17:11
I’m going to bet it fixes things, though I haven’t seen it before myself

ghaskins
2016-05-09 17:11
regarding the test instructions, I too have been bit by the doc reorg….FYI the “go test” instructions that used to be on the main readme are now here: https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/install.md

ghaskins
2016-05-09 17:12
which is via the “Installation” link that is mid-way down the page

ghaskins
2016-05-09 17:12
FYI, I have an oustanding PR (1390) that simplifies this a bit: you just run “make unit-test” instead of needing to paste that command

jyellick
2016-05-09 17:12
Thanks @ghaskins, our `CONTRIBUTING.md` file link to the test is broken now too, I'll submit a PR to fix it later today

ghaskins
2016-05-09 17:13
yeah, there are some other broken links too, i filed an issue

jyellick
2016-05-09 17:14
Yes, I am definitely in favor of those changes in 1390, would be a productivity boost for everyone I think

ghaskins
2016-05-09 17:15
regarding OOM, I havent seen that exact error, but while working on the baseimage I did note that we seem to blow out of the 4GB fairly easily

ghaskins
2016-05-09 17:15
im guessing we get away with it typically b/c there must be sufficient swap, but I didnt follow up

ghaskins
2016-05-09 17:16
its kind of tough, b/c 4GB is already fairly resource intensive for people working on smaller machines

jyellick
2016-05-09 17:19
Obviously the lower the barrier to entry, the better, but there's got to be a line somewhere. I wonder if 4GB is it, or if we could bump it slightly.

jyellick
2016-05-09 18:16
@sheehan: @jeffgarratt @ghaskins So I figured out what the problem was. When the peer tries to build the docker image, it uses a build context of $GOPATH, which, thanks to running some stress tests had several GB of logs in it, so when `vm.go` tries to build an entire tar file, in RAM, with the whole $GOPATH, we're running out of memory.

jyellick
2016-05-09 18:18
Do we think this is desirable behavior? I've certainly streamed huge tars via a pipe into docker to use a build context, and I didn't think docker buffered the whole thing (but rather wrote it out to the filesystem as it received it), is there a reason we aren't using this sort of streaming approach?

muralisr
2016-05-09 18:18
@jyellick: I have run into that myself

muralisr
2016-05-09 18:23
but my crash was when writing large deply tran to the ledger and not while constructing the tar file

muralisr
2016-05-09 18:24
are you running into nomem when creating the tar ?

cbf
2016-05-09 18:30
@sheehan: @ghaskins @binhn I think that if we are going to have what amounts to a checklist in the PR template (a Good Thing(tm)) then I think we need to align that with some published coding guidelines. We have https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/install.md#coding-golang- but I think this is misplaced. It should be in https://github.com/hyperledger/fabric/blob/master/CONTRIBUTING.md and we likely should have something to say about all languages used (thus far, we have golang, java, js, and python). Maybe we need separate doc for coding-style eg. https://github.com/electron/electron/blob/master/docs/development/coding-style.md

cbf
2016-05-09 18:30
thoughts?

jyellick
2016-05-09 18:33
@muralisr: This is when creating the tar, I am 99% certain. Currently running tests after cleaning up my env, but will attempt to reproduce after

muralisr
2016-05-09 18:34
ok

muralisr
2016-05-09 18:35
I wanted to create an issue for getting mimimal set of files for chaincode … currently we copy the world.

muralisr
2016-05-09 18:36
that would take care of this (bddtests will be ignored)

muralisr
2016-05-09 18:38
this would be necessary but not sufficient for issues regarding maximum tran size

sheehan
2016-05-09 18:48
@cbf: agreed, there are a number of sections in “Install” that don’t make sense. "Coding Golang” (already in main README) “Communication” (already in main README) "Code contributions” (contributing) "Generating gRPC code” (contributing) "Adding or updating Go packages” (contributing) @binhn: @joshhus would you support these changes?

joshhus
2016-05-09 18:48
has joined #fabric-dev

jyellick
2016-05-09 18:51
@muralisr: I'd still consider changing the image construction to stream the tar in, rather than pulling it all into RAM, seems like that should still be faster, and accomodate those who wish to include large files in their images.

cbf
2016-05-09 18:51
@sheehan: agreed

muralisr
2016-05-09 18:52
@jyellick: could be nice, agreed. question is does the docker client support streaming

cbf
2016-05-09 18:52
@ghaskins: nice job on the make file

cbf
2016-05-09 18:52
I left some comments

jyellick
2016-05-09 18:52
@muralisr: The docker CLI certainly does, and I assume it uses the same API?

muralisr
2016-05-09 18:52
I meant the go client, sorry

jyellick
2016-05-09 18:53
Yes, I'm not sure, if we think it's worth investigating, I can open an issue

muralisr
2016-05-09 18:53
sure

cbf
2016-05-09 18:56
heh, we reached 50 committers on fabric

cbf
2016-05-09 19:12
@tamas: @sheehan we need to clean up some of the README.md and contributing.md references that pertain to DAH (mailing list references, merge contact, etc) in https://github.com/hyperledger/fabric-api

tamas
2016-05-09 19:12
has joined #fabric-dev

sheehan
2016-05-09 19:13
yes, this repo is still in progress

sheehan
2016-05-09 19:13
I’ll add a PR to say that in the README

jyellick
2016-05-09 19:25
@sheehan: Using the new PR template, and running `gometalinter`, seeing just tons of warnings/errors, for instance in `core/peer` I get 917 of them, almost all of which are definitely outside the scope of my PR. I'm assuming we shouldn't mix generic lint cleanup in with more structural changes? Do we have a plan in place to get the whole codebase passing under the linting?

sheehan
2016-05-09 19:26
@jyellick: first plan is to remove gometalinter checkbox in PR and replace with goimports, go vet, and golint. https://github.com/hyperledger/fabric/pull/1415

sheehan
2016-05-09 19:27
and say that people just need to clean up code additions and modifications

sheehan
2016-05-09 19:29
For existing code, I was hoping we could slowly clean it up as we go.

cbf
2016-05-09 19:32
If using atom, then the configuration would be:

cbf
2016-05-09 19:32
--vendor, --disable-all, --enable=vet, --enable=golint, --enable=goimports --tests, --json, .

cbf
2016-05-09 19:32
configuration for gometalinter

ghaskins
2016-05-09 19:34
I think that whatever tooling/standard we decide on, it would be useful to have two things considered: 1) there should be the ability to specify exceptions (to deal with things we disagree with the tooling on, or decide we dont want to fix right now, etc). and 2) there should be a global pass to fix up any of the formatting things we want to fix, and exception the things we don’t that is independent of any logic changes

ghaskins
2016-05-09 19:34
and then flip the switch for CI to monitor for any newly introduced issues

ghaskins
2016-05-09 19:35
users would then either be able to submit new exceptions (with justifications) in their PR, or CI will find anything new without maintainer burden to check

ghaskins
2016-05-09 19:36
not sure the exception mechanism is available in any of the tooling, however

ghaskins
2016-05-09 19:36
would just be nice to have, based on my experience with other languages (like using coverity on C++)

ghaskins
2016-05-09 19:37
I guess “flip the CI switch” and “add the checklist item” would ideally be atomic too

jeroiraz
2016-05-09 19:37
has joined #fabric-dev

binhn
2016-05-09 20:28
@sheehan: agreed

binhn
2016-05-09 20:31
@ghaskins: read through #1390 — good idea, and it looks like you’ve covered quite a lot already that we can merge now

binhn
2016-05-09 20:33
@ghaskins: this will help when we want to generate custom build of the fabric

ghaskins
2016-05-09 20:35
@binhn: i think/hope/believe so

cbf
2016-05-09 20:53
@ghaskins: d’accord

cbf
2016-05-09 20:54
we should actively encourage people to take on linting of files with known lint warnings

cbf
2016-05-09 20:54
I could add an issue for each file with lint errors

ghaskins
2016-05-09 20:54
yeah, sounds good

cbf
2016-05-09 20:54
crowd source the cleanup

ghaskins
2016-05-09 20:55
some things will hopefully be automated (ala gofmt) but I suspect that is wishful thinking to expect all/most will get cleaned up that way

ramesh
2016-05-09 21:21
I have executed go lint and attached are the results..


privoal
2016-05-10 14:06
has joined #fabric-dev

ghaskins
2016-05-10 14:57
@bcbrock @vpaprots: FYI, I am working on a patch that builds on the new makefile plumbing that will treat the dockerhub repo for baseimage as optional

ghaskins
2016-05-10 14:58
meaning, if its not found, it will build it locally..dockerhub is just an optimization

ghaskins
2016-05-10 14:58
(and hooking the new $arch plumbing

simon
2016-05-10 15:11
makefile was unhappy, because my /var/hyperledger is not writable

ghaskins
2016-05-10 15:11
doing a dist-clean?

simon
2016-05-10 15:11
i need to either fix the tests not to require /var/hyperledger, or add +w in /var

simon
2016-05-10 15:12
i don't think it is good practice for build or test to write outside the source tree

simon
2016-05-10 15:12
but that's not your fault

ghaskins
2016-05-10 15:12
yeah, the only new thing that should be writing to var is the dist-clean target

ghaskins
2016-05-10 15:12
and in light of the fact that I switched the unit-test to use docker for the peer, I could argue we probably dont need the dist-clean target any more anyway

ghaskins
2016-05-10 15:13
but I am confused why this introduced a new problem for you

ghaskins
2016-05-10 15:14
unless I am misunderstanding, whatever is writing to /var must have been doing that before the makefile change right?

simon
2016-05-10 15:15
yea, i must have overwritten the path somehow

vpaprots
2016-05-10 15:15
has joined #fabric-dev

sheehan
2016-05-10 16:40
: Two PRs have been merged that will require a `vagrant destroy` `vagrant up` for those using vagrant. These changes rebrand the docker image under the hyperledger name and change the docker port to use the default value of 2375. Thanks @ghaskins and @bcbrock for these changes. https://github.com/hyperledger/fabric/pull/1411 https://github.com/hyperledger/fabric/pull/1422

suma
2016-05-10 16:40
gr8

arnaud
2016-05-10 16:41
thanks for the heads-up

ghaskins
2016-05-10 16:41
Related: things will (hopefully) go smoother if people a) adopt the new makefile mechanism, and b) use a workflow like “git pull && make clean peer” anytime you change HEAD

ghaskins
2016-05-10 16:41
this will ensure the system has a chance to reconcile your environment (vagrant or not) with the tree, and require fewer vagrant destroy/up cycles in the future

arnaud
2016-05-10 16:42
oh, so the make PR was landed too?

ghaskins
2016-05-10 16:42
yes, yesterday

ghaskins
2016-05-10 16:42
its use is currently optional, the old methods will still work

ghaskins
2016-05-10 16:42
but it is encouraged to adopt

arnaud
2016-05-10 16:42
cool, thanks

sheehan
2016-05-10 16:43
yes, sorry @arnaud. I think make impacts https://github.com/hyperledger/fabric/pull/1357. I was waiting to see if there were additional comments

arnaud
2016-05-10 16:45
yeah, I saw there is a new conflict

arnaud
2016-05-10 16:45
but I'm going to wait for the discussion on the command name to settle before I bother rebasing

arnaud
2016-05-10 16:46
unless we can quickly converge on a new name we probably should just keep the current one though

arnaud
2016-05-10 16:46
although not perfect it is the status quo :simple_smile:

ghaskins
2016-05-10 16:54
I think the proposed changes are reasonable and a positive step forward

ghaskins
2016-05-10 16:55
anything beyond that is probably a bigger/slower discussion and probably should be tackled as a sep issue

arnaud
2016-05-10 16:57
indeed, we could always rename the command later anyway

arnaud
2016-05-10 16:58
this is fairly orthogonal to the PR I submitted

ghaskins
2016-05-10 16:58
agreed

sheehan
2016-05-10 17:03
+1 I think the change is better than what we have today

arnaud
2016-05-10 17:24
ok, I'll resolve the conflict then so you can land it if you want

cbf
2016-05-10 18:23
@sheehan: please send a note to the hyperledger-technical-discuss as well (if you haven’t already) about the change

ghaskins
2016-05-10 18:23

ghaskins
2016-05-10 18:23
@ramesh: ^^^^

cbf
2016-05-10 18:23
it bit me

sheehan
2016-05-10 18:24
@ghaskins: we’re investigating in #

ghaskins
2016-05-10 18:24
ah, ok, i dont think i am subscribed there, will join

cbf
2016-05-10 20:21
AFAICT we don’t have a means of identifying a version for the peer binary

cbf
2016-05-10 20:22
Seems to me that we should do so before we ship a release

cbf
2016-05-10 20:22
eg ./peer —version would simply print the version string assigned at the build

arnaud
2016-05-10 20:35
@cbf do we have a version number assigned somewhere already?

arnaud
2016-05-10 20:58
make unit-test fails on master?

arnaud
2016-05-10 20:58
? http://github.com/hyperledger/fabric/core/ledger/util [no test files] 2016/05/10 20:55:06 setting Number of procs to -1, was 2 2016/05/10 20:55:07 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:30303: getsockopt: connection refused"; Reconnecting to "0.0.0.0:30303" 2016/05/10 20:55:09 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:30303: getsockopt: connection refused"; Reconnecting to "0.0.0.0:30303" error connection to server at host:port = 0.0.0.0:30303 FAIL http://github.com/hyperledger/fabric/core/peer 2.716s

ghaskins
2016-05-10 20:59
hmm, it sounds like the peer wasnt started, but the makefile should have done that for you

sheehan
2016-05-10 20:59
been working for me, but I can give it quick try

ghaskins
2016-05-10 20:59
travis uses the same mechanism though, so it should be generally sound..not sure whats up

arnaud
2016-05-10 20:59
who the hell made that makefile? :wink:

ghaskins
2016-05-10 21:00
some slacker

arnaud
2016-05-10 21:00
lol

arnaud
2016-05-10 21:00
I'm actually quite thankful!

ghaskins
2016-05-10 21:00
well, not if it doesnt work right :wink:

arnaud
2016-05-10 21:00
I feel much more at home now :simple_smile:

ghaskins
2016-05-10 21:01
any chance you already had a peer running, perhaps with security on?

ghaskins
2016-05-10 21:01
i didnt test how it would respond if another peer was competing for 30303

arnaud
2016-05-10 21:02
hmm, actually, if I start the peer by hand first the test passes

arnaud
2016-05-10 21:02
so let me see if something got screwed up somewhere

ghaskins
2016-05-10 21:03
hmm, its supposed to launch the peer within a docker container for you

arnaud
2016-05-10 21:04
yeah, I see that in the makefile

arnaud
2016-05-10 21:04
I wonder why it didn't happen

arnaud
2016-05-10 21:05
I've got to take a short break, I'll be back later

arnaud
2016-05-10 21:06
if this is just something on my side I'll figure it out

ghaskins
2016-05-10 21:09
ok, obviously they are wet bits, so its possible you hit a corner case we didnt see before

arnaud
2016-05-10 21:45
I'm sensing that the problem comes from running with old images

arnaud
2016-05-10 21:45
I did a vagrant destroy and up but I didn't do a make clean - my bad

arnaud
2016-05-10 21:45
I'm waiting to see but I bet that's the problem

arnaud
2016-05-10 21:49
bingo!

arnaud
2016-05-10 21:49
pfff. silly me

ghaskins
2016-05-10 21:56
oh, thats weird only in the sense that the makefile is new such that I wouldnt have thought a clean would do anything w.r.t. old non-makefile state

ghaskins
2016-05-10 21:56
but whatever works

ghaskins
2016-05-10 21:57
i like zero-pr-required solutions :wink:

ghaskins
2016-05-10 21:57
something to keep an eye on though, as I bet you wont be the last

arnaud
2016-05-10 21:57
:simple_smile:

arnaud
2016-05-10 21:58
yeah, looking at the makefile, I'm not sure why that did the trick either

arnaud
2016-05-10 22:00
maybe it's just some odd state on my machine, it seems prone to that

arnaud
2016-05-10 22:01
for some reason emacs kept changing the permission of all the files I saved, I had to reinstall it and the problem is gone

arnaud
2016-05-10 22:01
I've never seen that before

ghaskins
2016-05-10 22:03
actually, if you did a vagrant up with the new code, it should have done an implicit clean

ghaskins
2016-05-10 22:03
so there might be more to the story

arnaud
2016-05-10 22:03
that was my assumption


ghaskins
2016-05-10 22:04
that should have been run as the vagrant environment finished provisioning

arnaud
2016-05-10 22:04
indeed

arnaud
2016-05-10 22:04
this is even more mysterious now...

arnaud
2016-05-10 23:12
all right, I rebased PR#1357. It'd be nice if I didn't have to do it yet again given that I've already done that like 4 times... 0:-)

ghaskins
2016-05-10 23:24
does anyone know the history of why we install nodejs from a raw binary package instead of using the one in ubuntu

cbf
2016-05-10 23:43
2016/05/10 23:34:26 Failed Chaincode docker build: Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage --- FAIL: TestVM_BuildImage_ChaincodeLocal (17.54s) vm_test.go:105: Error building Chaincode container: Error building Chaincode container: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage FAIL FAIL http://github.com/hyperledger/fabric/core/container 49.217s

cbf
2016-05-10 23:43
just now… is there a known issue?

ghaskins
2016-05-10 23:43
not that I am aware of, this is using the make based environment?

cbf
2016-05-10 23:44
yes

cbf
2016-05-10 23:44
make all

cbf
2016-05-10 23:44
re-running

ghaskins
2016-05-10 23:44
hmm, can you post “docker images” outut

ghaskins
2016-05-10 23:45
one thing I am seeing working on the z support, it doesnt seem that errors propagate all the way out of the docker provisioner, so its possible that something died but the system still throught the dep was satisfied

ghaskins
2016-05-10 23:45
thats the only thing I can think of

ghaskins
2016-05-10 23:47
@cbf: based on your output, I think you have pulled across the docker rebranding fix pushed earlier today and need a vagrant destroy/up cycle

cbf
2016-05-10 23:48
gah

ghaskins
2016-05-10 23:48
that would explain what you are seeing…the images are cached as openblockchain in your environment, but the code is looking for HL branded

cbf
2016-05-10 23:48
ok

ghaskins
2016-05-10 23:48
rule of thumb (for now), move HEAD?, make clean

ghaskins
2016-05-10 23:48
if I can get the deps more intelligent, we can get rid of that

ghaskins
2016-05-10 23:49
but for now, thats the safest

ghaskins
2016-05-11 11:59

bsmita
2016-05-11 11:59
has joined #fabric-dev

yacovm
2016-05-11 12:38
Hey, were there any recent (this week) commits that could have impacted performance (to be exact- throughput)?

simon
2016-05-11 12:53
nothing real significant, i don't think

vpaprots
2016-05-11 13:28
FYI @dan.mccarty @jkirke: Greg and I tried his patch last night on LinuxONE, `make unit-tests` pass, but behave tests have some failures, the ones I was showing @bmos299 in Raleigh and mentioned on the call yesterday

arnaud
2016-05-11 16:07
I notice that @vpaprots wrote "make unit-tests", yet the Makefile target is make unit-test

vpaprots
2016-05-11 16:08
my mistake :simple_smile:

arnaud
2016-05-11 16:08
it's not a big deal but I too was expecting it to be unit-tests rather than unit-test

ghaskins
2016-05-11 16:08
actually that bothers me too, heh

arnaud
2016-05-11 16:09
maybe we could add unit-tests

ghaskins
2016-05-11 16:09
probably should make it plural

vpaprots
2016-05-11 16:09
heh.. didn't want to switch windows to look up the spelling and that what happens..

arnaud
2016-05-11 16:09
keep unit-test for backward compatibility

ghaskins
2016-05-11 16:09
yeah, though that compatibility is like 36h :wink:

ghaskins
2016-05-11 16:09
i could be convinced either way

arnaud
2016-05-11 16:10
I know :simple_smile:

arnaud
2016-05-11 16:13
but it also means you can just change the Makefile without updating the docs :wink:

ghaskins
2016-05-11 16:19
yeah, understood

ghaskins
2016-05-11 16:19
another PR cycle ensues

muralisr
2016-05-11 16:21
@ghaskins: (based on a older conversation with @vpaprots …) trying to understand arch substrate and how it will be used. So the substrate provides the image support to build upon arch specific env. Would each arch the provide its core.<arch>.yaml file covering all things for that arch (defaulting to core.yaml if arch not found) ? So the arch image + arch yaml file should make the dev env work as-is without changes ?

muralisr
2016-05-11 16:21
lots of assumptions there… won’t be offended if everything is crossed out :simple_smile:

ghaskins
2016-05-11 16:22
@muralisr: i havent seen anything that would require arch specifics at the yaml level

ghaskins
2016-05-11 16:23
(that doesnt mean there arent going to be those types of issues, i am just saying I am not aware of any)

ghaskins
2016-05-11 16:23
right now, the approach is more environmental: getting the prerequisites like go/node/docker in the same shape they are on x86

ghaskins
2016-05-11 16:24
part of this was addressing the fact that our dockerhub images historically have been implicitly x86

ghaskins
2016-05-11 16:24
so, that is broken out now, tagged by $arch

ghaskins
2016-05-11 16:25
but it gets normalized on import so the golang/yaml code doesnt need to know that, just like it doesnt need to know that the “docker” binary is compiled different

muralisr
2016-05-11 16:25
I see

ghaskins
2016-05-11 16:26
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F18215ECC/-.sh and commented: For instance, this is what we see now...

muralisr
2016-05-11 16:26
so docker takes care of finding the right arch image

ghaskins
2016-05-11 16:26
it treats dockerhub as a cache…and looks for an $arch specific artifact

muralisr
2016-05-11 16:26
got it

muralisr
2016-05-11 16:26
that helps

muralisr
2016-05-11 16:26
thank you :simple_smile:

ghaskins
2016-05-11 16:26
if its not found in the cache, it builds it locally

ghaskins
2016-05-11 16:27
(though this should really be a stop-gap situation, building locally is painful, ala the old OBC way

ghaskins
2016-05-11 16:28
once its imported, its stored as “hyperledger/fabric-baseimage:latest” regardless of $arch, so then the YAML files can remain unaware

muralisr
2016-05-11 16:29
ok

muralisr
2016-05-11 16:30
that covers my question. thanks!

ghaskins
2016-05-11 16:30
cool

plucena
2016-05-11 18:02
has joined #fabric-dev

sheehan
2016-05-11 18:22
dumb question, would like a second opinion. In chaincode.proto, we have `ChaincodeSpec` which has a `ChaincodeInput` type named `ctorMsg`. I’m in the process of renaming `ctorMsg`. Do people prefer `input` or `chaincodeInput`?

muralisr
2016-05-11 18:24
+1 for input (avoid stutter)

ghaskins
2016-05-11 18:24
I agree with murali

sheehan
2016-05-11 18:25
thanks, that’s what I was thinking and wanted to make sure others agreed

arnaud
2016-05-11 18:35
+1 for input

arnaud
2016-05-11 20:55
@muralisr: what platform are you working on?

muralisr
2016-05-11 20:56
my ubuntu is gathering dust now that I’m on Mac full time :simple_smile:

arnaud
2016-05-11 20:56
I'm looking into the file modes issue and noticed that there is a new go file you just added and it has the wrong permissions

muralisr
2016-05-11 20:56
ok

arnaud
2016-05-11 20:56
fabric/examples/chaincode/go/passthru/passthru.go

muralisr
2016-05-11 20:56
let me check what I have

arnaud
2016-05-11 20:56
it's got +x

arnaud
2016-05-11 20:56
you should check what permissions you get when you create a new file

muralisr
2016-05-11 20:57
all my examples have got +x

arnaud
2016-05-11 20:58
I'm putting a PR together to fix all the permissions but we also need to make sure we don't keep creating files with the +x when they shouldn't

arnaud
2016-05-11 20:58
don't worry about the existing files, they will get fixed


muralisr
2016-05-11 20:59
do you have them without x in your vagrant env ?

arnaud
2016-05-11 20:59
just look into what you do to create new files and what permissions you get

arnaud
2016-05-11 20:59
oh... in vagrant on my side it's a complete mess :simple_smile:

muralisr
2016-05-11 20:59
:simple_smile:

arnaud
2016-05-11 20:59
I can't rely on that at all

muralisr
2016-05-11 20:59
let me check on the platform

arnaud
2016-05-11 21:00
I do all my git operations outside of vagrant

muralisr
2016-05-11 21:00
so do I


arnaud
2016-05-11 21:00
in vagrant all the files are -rwxrwxrwx 1 vagrant vagrant filename!

muralisr
2016-05-11 21:00
that’s example 02 on mac

arnaud
2016-05-11 21:01
ok, but try to create a new one, just to test

muralisr
2016-05-11 21:01
sure

arnaud
2016-05-11 21:01
and see what you get


arnaud
2016-05-11 21:01
ok, so that's good

muralisr
2016-05-11 21:02
I’ll make sure there’s no x next time I create a file

arnaud
2016-05-11 21:02
and try to edit and save?

arnaud
2016-05-11 21:02
my emacs was changing the permission on save and adding +x for some reason

muralisr
2016-05-11 21:02
no x

muralisr
2016-05-11 21:02
I used vi

arnaud
2016-05-11 21:02
ok so you should be good

arnaud
2016-05-11 21:02
you're a warrior my friend!

muralisr
2016-05-11 21:02
wonder wjy passthru.go came out as x

arnaud
2016-05-11 21:03
vi!... :wink:

arnaud
2016-05-11 21:04
well, you should be ok but beware moving forward

arnaud
2016-05-11 21:04
I hadn't realized until various people noticed the unwanted chmod in my PRs

arnaud
2016-05-11 21:05
I finally found the source of the problem and had to reinstall a different emacs to fix it

arnaud
2016-05-11 21:05
given how many files have +x throughout the project there are other people with that kind of problems somehow

muralisr
2016-05-11 21:08
right… I’ll look for perms going forwards. just assumed they were ok

arnaud
2016-05-11 21:10
I just submitted a PR, I found 469 files with +x for no good reason

arnaud
2016-05-11 21:10
out of 1328 files total that's a good chunk...

arnaud
2016-05-11 21:11
actually it's out of 1014

arnaud
2016-05-11 21:11
so about half of the files

ghaskins
2016-05-11 21:59
@arnaud: it makes me wonder if we could hook “make linter” to do something like “git ls-files” and throw a WARNING/ERROR if any are found with +x set

ghaskins
2016-05-11 21:59
might need some refinement (for instance, if some files are supposed to be +x

ghaskins
2016-05-11 22:00
actually, that is almost certainly true

ghaskins
2016-05-11 22:00
perhaps “find . -name “*.yaml” -and -name “*.go” etc

arnaud
2016-05-11 22:34
indeed for specific file types we could do something like that

arnaud
2016-05-11 22:34
you can use -executable to quickly spot the files with +x

cbf
2016-05-12 10:49
I was playing around with that

maro
2016-05-12 16:15
has joined #fabric-dev

bcbrock
2016-05-12 23:27
Am I the only one for whom the Go unit tests do not work for the latest Master version? commit 8b6eb2ff1f253d3a3546d99d1ff9f6a79442192c Merge: 509b2d6 4e19fa4 Author: Sheehan Anderson <sranderson@gmail.com> Date: Thu May 12 15:13:12 2016 -0400 Merge pull request #1463 from novusopt/issue-1462 Use new peer command in the docker-compose files

bcbrock
2016-05-12 23:27
14162:--- FAIL: TestBatchCustody (6.01s) 49771:http://FAILgithub.com/hyperledger/fabric/consensus/obcpbft 60.635s

bcbrock
2016-05-12 23:29
I see the same error on X86 and POWER

jyellick
2016-05-13 01:10
This is a broken test, working to find a solution, but we should probably comment it out for now. It is a byzantine code path, so, probably safe enough not to revert that whole pr

isidoro.ghezzi
2016-05-13 11:04
has joined #fabric-dev

paulx
2016-05-13 11:39
has joined #fabric-dev

dmurik
2016-05-13 14:50
has joined #fabric-dev

david.acton
2016-05-13 16:09
has joined #fabric-dev

mgutala
2016-05-13 19:33
has joined #fabric-dev

mgutala
2016-05-13 19:35
I am trying to test peer in chaincode dev mode with security enabled. I followed instructions and get this error when I am trying to deploy chain code "Registration to the Membership Service required."

mgutala
2016-05-13 19:35
./peer chaincode deploy --username=jim -n mycc -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'

mgutala
2016-05-13 19:36
Error: Error building chaincode: rpc error: code = 2 desc = "Registration to the Membership Service required."

sheehan
2016-05-13 20:01
@adc: or @diego_m should be able to help.

diego_m
2016-05-13 20:01
has joined #fabric-dev

adc
2016-05-13 20:01
has joined #fabric-dev

sheehan
2016-05-13 20:01
which doc are you following?


muralisr
2016-05-13 21:25
@mgutala: can you try CORE_SECURITY_ENABLED=true ./peer chaincode deploy --username=jim -n mycc -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'

muralisr
2016-05-13 21:25
basically add "CORE_SECURITY_ENABLED=true"

davidjhowie
2016-05-14 08:24
has joined #fabric-dev

jianzhang98
2016-05-14 21:53
has joined #fabric-dev

mikezaccardo
2016-05-16 16:51
has joined #fabric-dev

popldo
2016-05-17 02:49
has joined #fabric-dev

sheehan
2016-05-17 13:59
@muralisr: @robert was trying to connect to event services and it did not seem to be working. I noticed events port (31315) is missing from the vagrant file. https://github.com/hyperledger/fabric/blob/master/devenv/Vagrantfile#L37 Should I add it or is there a reason it is missing?

robert
2016-05-17 13:59
has joined #fabric-dev

muralisr
2016-05-17 14:25
@sheehan: port mapping between vagrant and workstation you mean ? we could add it.

robert
2016-05-17 14:26
Thanks, @muralisr

muralisr
2016-05-17 14:27
@robert: anything for you :simple_smile: … do let me know if you need anything

mgutala
2016-05-17 15:11
I get this error when I run app.go from asset_management chaincode example. I built app, copied core.yaml to http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management/app. and ran app

mgutala
2016-05-17 15:11
2016/05/17 14:47:10 Wait 30 seconds 2016/05/17 14:47:40 ------------- Done! 2016/05/17 14:47:40 ------------- Bob wants to assign the asset 'Picasso' to Charlie... 2016/05/17 14:47:40 Resp [status:SUCCESS msg:"d034c26c-cd20-4422-a87d-0e2f017c192c" ] 2016/05/17 14:47:40 Wait 30 seconds 2016/05/17 14:48:10 Query.... 2016/05/17 14:48:40 Resp [status:FAILURE msg:"Error:Failed to execute transaction or query(Timeout expired while executing transaction)" ] 2016/05/17 14:48:40 Query....done 2016/05/17 14:48:40 [client.lukas] Failed decrypting query result [cipher: message authentication failed]. 2016/05/17 14:48:40 Failed decrypting result [Decryption failed.] 2016/05/17 14:48:40 Failed assigning ownership [Decryption failed.] 2016/05/17 14:48:40 Failed testing asset management chaincode [Decryption failed.]

mgutala
2016-05-17 15:59
I also see this error in vp logs

mgutala
2016-05-17 15:59
^[[31m14:48:10.704 [chaincode] processStream -> ERRO ba69^[[0m Error handling chaincode support stream: connection error: desc = "transport is closing"

robert
2016-05-17 16:21

muralisr
2016-05-17 16:37
that’ll work @robert. Thanks!

ghaskins
2016-05-17 19:29
@arnaud: thanks for the auto-yaml-path fix, that is quite nice

ghaskins
2016-05-17 19:30
@sheehan: i wonder if we should switch to using go-install so that the binaries end up in $GOPATH/bin and we no longer need the “cd ./peer” type instructions

ghaskins
2016-05-17 19:31
it seems with @arnaud’s patches, we no longer need to be concerned about the location of the binary, $GOPATH/bin is already in the $PATH, so why not

ghaskins
2016-05-17 19:31
thoughts?

ghaskins
2016-05-17 19:31
(actually there are other reasons to want to use go-install too, it might be faster to build than go-build (TBD)

sheehan
2016-05-17 19:31
I guess it would be a different folder in the host and Vagrant

sheehan
2016-05-17 19:31
not sure that matters though

ghaskins
2016-05-17 19:32
i dont think it does since it gets normalized by $GOPATH/bin

sheehan
2016-05-17 19:33
why is go-install potentially faster?

ghaskins
2016-05-17 19:33
i have yet to personally confirm this, but ive seen anecdotal rumblings on the net that go-install takes advantage of object-caching whereas go-build does not

ghaskins
2016-05-17 19:34
e.g. its smarter about understanding what actually needs to be rebuilt

ghaskins
2016-05-17 19:34
id have to experiment to see if that is really true though

ghaskins
2016-05-17 19:34
(side-note: if that is true and we do migrate to it, we’d need to make sure “make clean” calls “go clean” so that the object cache is properly addressed

ghaskins
2016-05-17 19:35
which we should probably do anyway

ghaskins
2016-05-17 19:35
ill file an issue so it doesnt get lost

sheehan
2016-05-17 19:36
hopefully Go 1.7 will help with compile times also


ghaskins
2016-05-17 19:41
@sheehan: not sure how true this is, but this is the gist of what I have seen: https://www.quora.com/What-is-the-difference-between-build-and-install-in-Go

sheehan
2016-05-17 19:41
whoa, that’s a big diff if true

arnaud
2016-05-17 19:53
@ghaskins the reliance on running programs from a specific directory drives me nuts because I typically don't :slightly_smiling_face:

arnaud
2016-05-17 19:54
so I would be happy with using go install,

ghaskins
2016-05-17 19:54
cool

ghaskins
2016-05-17 19:54
ill prototype it out and see how it works

arnaud
2016-05-17 19:54
cool

arnaud
2016-05-17 20:52
who's familiar with the chaincode handling code? I'm looking into the use of GOPATH and I'm rather puzzled by the code I see

arnaud
2016-05-17 20:52
specifically I'm looking into why chaincode deployment fails when GOPATH has more than one element

muralisr
2016-05-17 20:54
@arnaud: how is it failing ?


arnaud
2016-05-17 20:55
it seems to be a rather convoluted way of doing a simple os.Getenv("GOPATH")

arnaud
2016-05-17 20:55
do you know any reason this is done that way?

arnaud
2016-05-17 20:56
@muralisr: if you simply set say GOPATH="/opt/gopath:/opt/go" for instance, the chaincode will fail to load

arnaud
2016-05-17 20:57
$ go test -v -run=TestExecuteDeployTransaction 2016/05/17 20:40:39 setting Number of procs to -1, was 2 === RUN TestExecuteDeployTransaction 2016/05/17 20:40:39 Chaincode support using peerAddress: 0.0.0.0:40303 getting deployment spec for chaincode spec: type:GOLANG chaincodeID:<path:"github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01" > ctorMsg:<function:"init" args:"a" args:"100" args:"b" args:"200" > --- FAIL: TestExecuteDeployTransaction (2.00s) exectransaction_test.go:192: Error deploying <>: code does not exist Download failer open /opt/gopath:/opt/go/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01: no such file or directory FAIL

arnaud
2016-05-17 20:58
that's because it simply appends the chaincode url to the gopath

arnaud
2016-05-17 20:58
without paying attention to the fact that gopath may have more than one dir

arnaud
2016-05-17 20:58
at the very least we ought to take the first element only or, better, try them all until one works

arnaud
2016-05-17 20:59
I'm working on that fix but I don't understand why we're walking through the whole os.Environ() map to find GOPATH

muralisr
2016-05-17 20:59
let me check

muralisr
2016-05-17 21:00
that would certainly work. I probably just did not look for os.Getenv

arnaud
2016-05-17 21:00
ok

arnaud
2016-05-17 21:00
just wanted to make sure I wasn't missing something

muralisr
2016-05-17 21:01
good catch, thanks! :simple_smile:

arnaud
2016-05-17 21:01
it's too easy to think you are smarter than your colleagues and miss something :wink:

muralisr
2016-05-17 21:01
well, at least not in this case :simple_smile:

muralisr
2016-05-17 21:02
right

muralisr
2016-05-17 21:02
let me think thru this a bit….

arnaud
2016-05-17 21:03
sure

muralisr
2016-05-17 21:08
the code assumes the first element in the GOPATH contains the code. Do you plan to walk all the elements and find the first that matches and return that ?

muralisr
2016-05-17 21:10
or were you planning to keep that assumption but make sure the code picks up the first element (instead of the entire string)

arnaud
2016-05-17 21:26
I'm not sure

arnaud
2016-05-17 21:27
I was going to explore a bit and see what it would take

arnaud
2016-05-17 21:27
I think walking the list would be the best

arnaud
2016-05-17 21:28
given that it's how GOPATH is supposed to be used

arnaud
2016-05-17 21:28
right now from what I can tell it doesn't even just take the first element

arnaud
2016-05-17 21:28
it takes the whole thing as is, which is why it fails

muralisr
2016-05-17 21:32
right

muralisr
2016-05-17 21:32
and for the example above, it’ll work if you use the first element

arnaud
2016-05-17 21:33
yes

arnaud
2016-05-17 21:33
that's the most basic fix I would do if nothing else

arnaud
2016-05-17 21:33
we could then say "make sure your chaincode is found first in your GOPATH"

arnaud
2016-05-17 21:33
which is okay

arnaud
2016-05-17 21:34
I'll dig a bit and see what I can get

arnaud
2016-05-17 21:34
I'll let you know

arnaud
2016-05-17 21:34
thanks

muralisr
2016-05-17 21:36
right

muralisr
2016-05-17 21:36
and in other envs such as SDK, docker, etc. that’s a non-issue (in general) so its not a far-fetch

arnaud
2016-05-17 21:36
ah ok, good to know

rupendradhillon
2016-05-18 04:53
has joined #fabric-dev


simon
2016-05-18 11:00
this is an interesting question

simon
2016-05-18 11:01
should we provide a deterministic randomness to the chaincode?

mcrafols
2016-05-18 13:36
@simon: could it be for example just the hash of the chaincode?

mcrafols
2016-05-18 13:36
how is it currently determined?

simon
2016-05-18 13:42
what is?

mcrafols
2016-05-18 13:43
the deploy transaction id

ghaskins
2016-05-18 14:59
@simon: I suppose if necessary we could have some facility where the deployment seeds a PRNG deterministically, but i am thinking for this use case its not really necessary

ghaskins
2016-05-18 14:59
a monotonically increasing sequence number facility would do the trick

ghaskins
2016-05-18 14:59
this could be implemented directly in the putstate

mcrafols
2016-05-18 15:55
@ghaskins: do you know how it is currently determined?

mcrafols
2016-05-18 15:55
is it the VP where it is sent who chooses it?

ghaskins
2016-05-18 15:56
the hash?

ghaskins
2016-05-18 15:57
as a general statement, pretty much everything we do within the fabric needs to be deterministic, and the hash computation is no different

ghaskins
2016-05-18 15:58
each VP should compute the hash on their own

dmurik
2016-05-18 15:58
@simon: @ghaskins: The Go chaincode has access to stub.GetTxTimestamp() which is deterministic. Is a SHA(txTimestamp) good enough? (usage example in chaincode_example01.go)

ghaskins
2016-05-18 15:58
@dmurik: i would think so, though I still think its overkill w.r.t. the OP question

ghaskins
2016-05-18 15:58
but yes

ghaskins
2016-05-18 15:59
you would want to be careful about clock granularity though

dmurik
2016-05-18 16:00
@ghaskins: You're right - two transactions in same millisecond (or so) will create identical hash values. Your answer on StackOverflow makes sense to me (just keep a counter in the world state).

simon
2016-05-18 16:04
don't keep a counter

simon
2016-05-18 16:05
that is a congestion point - all transactions need to serialize around the counter

mcrafols
2016-05-18 16:06
what I mean is that currently if you do a deploy transaction, an UID is returned, how is this UID determined?

simon
2016-05-18 16:07
mcrafols: devops creates the uuid, i think

ghaskins
2016-05-18 16:11
its a hash of various input parameters, like the code itself, the ctorMsg, etc

ghaskins
2016-05-18 16:11
i forget where it is computed in the code, but its a function of the inputs to the deploy


ghaskins
2016-05-18 16:12
but IIUC, that output is hashed further higher in the stack

ghaskins
2016-05-18 16:12
but the same concept applies: function of inputs

dmurik
2016-05-18 16:19
@simon: Re: "congestion point": I thought anyway all the transactions are serialized (in some way or another) so they are put in a strict order in the blockchain. Or, in other words, if the transactions don't modify the same key in the world state, will they be parallelized?

simon
2016-05-18 16:24
not at the moment

simon
2016-05-18 16:24
but you could, if they are independent

simon
2016-05-18 16:24
you certainly can't if they are all serialized around the counter

isidoro.ghezzi
2016-05-18 19:07
Hi all, I pulled the last commit on master (30399796913350ead56ec59cac16add658c39b3e): and unit tests fail: ``` --- FAIL: TestChaincodeInvokeChaincode (53.50s) exectransaction_test.go:675: Error invoking <b736a304eeda340a47c52c44367a28c8f41004518a4181eb7e8417a778ad3a4b4fe37ea149399cb7b27be88c3920025141cf4be0ebb7791e5968897bdc31d1b6>: Transaction or query returned with failure: [fa2b3f5b-d8db-4a43-a561-8dfc9f8d8254]Chaincode handler FSM cannot handle message (ERROR) with payload size (269) while in state: ready … FAIL exit status 1 FAIL http://github.com/hyperledger/fabric/core/chaincode 197.766s ```

ghaskins
2016-05-18 19:10
@isidoro.ghezzi: strange, I just confirmed that the PR that created 30399 did in fact pass CI

ghaskins
2016-05-18 19:10
is it repeatable?

isidoro.ghezzi
2016-05-18 19:17
yes it is:  ``` cd $GOPATH/src/github.com/hyperledger/fabric/core/chaincode/ go test -v -run=TestChaincodeInvokeChaincode … --- FAIL: TestChaincodeInvokeChaincode (48.37s) exectransaction_test.go:675: Error invoking <b736a304eeda340a47c52c44367a28c8f41004518a4181eb7e8417a778ad3a4b4fe37ea149399cb7b27be88c3920025141cf4be0ebb7791e5968897bdc31d1b6>: Transaction or query returned with failure: [c89c565e-027f-445d-8185-845cdde56ae9]Chaincode handler FSM cannot handle message (ERROR) with payload size (269) while in state: ready === RUN TestChaincodeInvokeChaincodeErrorCase … --- PASS: TestChaincodeInvokeChaincodeErrorCase (37.16s) FAIL exit status 1 FAIL http://github.com/hyperledger/fabric/core/chaincode 85.599s ```

muralisr
2016-05-18 20:05
@ghaskins: do you know if chaincode_example02 was changed ?

muralisr
2016-05-18 20:05
let me check

ghaskins
2016-05-18 20:05
@muralisr: not to my knowledge

muralisr
2016-05-18 20:05
ok

muralisr
2016-05-18 20:41
@isidoro.ghezzi: FWIW …. I ran "go test -run=TestChaincodeInvokeChaincode” and “go test” with latest and both worked

christophera
2016-05-19 00:01
@christophera has left the channel

mtakemiya
2016-05-19 08:29
has joined #fabric-dev

isidoro.ghezzi
2016-05-19 09:10
ok , TestChaincodeInvokeChaincode was failing because, of the presence of the binary chaincode file `http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02` i built before; removing it, made the test ending successfully. That sounds: "Before running unit-test remove any binary chaincode_example you built/compiled".

ghaskins
2016-05-19 11:28
There is a problem in general where otherwise innocuous state within your $GOPATH can mess up the unit tests, I am finding

ghaskins
2016-05-19 11:28
for instance, the other day I installed go-bindata in my vagrant to try an experiment and then the HL unit-tests were tripping over it

simon
2016-05-19 12:07
do we know how this happens?

ghaskins
2016-05-19 12:20
i think in my case, it had to do with the way the code tries to import the entire $GOPATH…there was something in go-bindata that the fs-copy was unhappy with…i think it was a symlink IIRC

ghaskins
2016-05-19 12:20
but I have seen other problems like people having large binaries in the tree and it blows out the memory of the peer when it tries to build the tarball for docker-build in memory

ghaskins
2016-05-19 12:21
it seems that generally speaking, assuming that the $GOPATH can just be blindly copied is problematic

simon
2016-05-19 12:30
yea

muralisr
2016-05-19 12:30
@isidoro.ghezzi: ah I should remember to ask about the binary :slightly_smiling_face:

muralisr
2016-05-19 12:32
@ghaskins: @simon a set of “typical” files that bloat the image and are unnecessary (1) the peer binary (2) membersrvc binary (3) behave log files if you run with -D logs=Y (4) any redirected “output” files from peer (5) executables left in examples when running in —peer-chaincodedev

muralisr
2016-05-19 12:35
I’ve been meaning to open an issue wanted to create a filter for chaincode tar file

muralisr
2016-05-19 12:35
what do you think ?

simon
2016-05-19 12:43
i think it may be better to collect the sources, rather blacklisting other files

ghaskins
2016-05-19 12:46
git ls-files may be helpful in this regard

simon
2016-05-19 12:52
yes

muralisr
2016-05-19 12:55
right. Some approach to collect minimal files

ramesh
2016-05-19 12:55
Hi All, can we integrate this link in our hyperledger/fabric Readme.md file? This is very useful to understand the status of 'go lint' 'go vet' 'misspell' and 'gofmt'


ramesh
2016-05-19 12:56
We can generate `go report` for each repository using `https://goreportcard.com/` link

gordonj
2016-05-19 13:47
has joined #fabric-dev

adriano
2016-05-19 15:47
has joined #fabric-dev

arnaud
2016-05-19 16:26
@muralisr: hi, do we really need to have the fabric source path in GOPATH when doing go get to download the chaincode?

arnaud
2016-05-19 16:27
this is what's preventing us from testing getCodeFromHTTP using a fabric example like http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01

arnaud
2016-05-19 16:27
because go get will find it in the Fabric source and won't download it

arnaud
2016-05-19 16:28
if we remove the fabric source from GOPATH then go get will download it to the temp directory effectively running through the whole getCodeFromHTTP code

arnaud
2016-05-19 16:29
I tested it within vagrant and I can remove it all right but I don't know whether this would cause problem for those who work outside vagrant

arnaud
2016-05-19 16:39
otherwise we'll always have to rely on some other repo, I used my fork and that works: http://github.com/lehors/fabric/examples/chaincode/go/chaincode_example01

arnaud
2016-05-19 16:39
but it doesn't seem right to have a test that relies on a separate repo

muralisr
2016-05-19 17:00
@arnaud: I’ll have to look but this was discussed in an issue. It boiled down to this - having to resolve remote when identical path existed locally. This should only be an issue with the examples in the fabric.

muralisr
2016-05-19 17:00
let me hunt down and issue and refresh my memory :slightly_smiling_face:

arnaud
2016-05-19 17:00
cool

arnaud
2016-05-19 17:01
if you find it, please, share the reference so I can read it and save you a rerun :slightly_smiling_face:

muralisr
2016-05-19 17:01
of course :slightly_smiling_face:

arnaud
2016-05-19 17:01
I have a simple fix to the GOPATH with multiple elements where I only take the first element

muralisr
2016-05-19 17:02
ok

arnaud
2016-05-19 17:02
I still don't know whether it's worth doing more

muralisr
2016-05-19 17:02
+1 for the fix and baby steps ?

arnaud
2016-05-19 17:02
yeah, that's a bit my thinking

muralisr
2016-05-19 17:02
it’ll certainly resolve the problem

muralisr
2016-05-19 17:02
ok

arnaud
2016-05-19 17:03
document the limitation and see if anyone complains

muralisr
2016-05-19 17:03
ok

arnaud
2016-05-19 17:05
otherwise the code assumes it will run on linux and liberally uses / for filepath separator, is there a policy in this regard?

arnaud
2016-05-19 17:05
shouldn't we use os.PathSeparator consistently?

arnaud
2016-05-19 17:06
that would be my inclination but I'm new to the project so I don't know if there was a decision made in this regard

arnaud
2016-05-19 17:06
some code uses os.PathSeparator some code doesn't

muralisr
2016-05-19 17:26

arnaud
2016-05-19 17:28
ok, I'll look, thanks

arnaud
2016-05-19 17:28
so, how does the getCodeFromHTTP get tested right now?

arnaud
2016-05-19 17:29
do we have any of the CI test covering that code?

arnaud
2016-05-19 17:34
very relevant thread indeed

arnaud
2016-05-19 17:35
another possibility would be to have a flag like -f/-force which when used would force the download

arnaud
2016-05-19 17:35
that could be handy for testing if nothing else

muralisr
2016-05-19 17:36
sure, but again, this is mainly a problem for fabric examples. Do you think a “-f” is warranted for that ?

muralisr
2016-05-19 17:36
just asking… maybe the answer is yes

arnaud
2016-05-19 17:36
if that's the only way to test: yes!

arnaud
2016-05-19 17:36
how is that getCodeFromHTTP tested?

arnaud
2016-05-19 17:37
other than by you I mean :slightly_smiling_face:

muralisr
2016-05-19 17:37
no unit test. It gets tested via external usage such as bluemix

muralisr
2016-05-19 17:37
right :slightly_smiling_face:

muralisr
2016-05-19 17:38

arnaud
2016-05-19 17:38
yes, that might be a reasonable trade-off

muralisr
2016-05-19 17:38
I hesitate introducing a new flag for this

arnaud
2016-05-19 17:39
I agree, it may not be worth it

arnaud
2016-05-19 17:39
it's not like I'm going to delete that fork any time soon so the dependency isn't so bad

arnaud
2016-05-19 17:40
I just don't like not having any tests

arnaud
2016-05-19 17:40
I'm touching that code and want to know there is a test to ensure I don't break it

arnaud
2016-05-19 17:40
ok, I'll put a test in with that

arnaud
2016-05-19 17:41
what about the PathSeparator stuff?

muralisr
2016-05-19 17:46
I have think about it… a grep show that is used in only one place in the fabric code. I’m sure path is spread around all over

arnaud
2016-05-19 17:55
ok, I'll leave that alone for now then

arnaud
2016-05-19 17:55
this is something that could be done at some point

muralisr
2016-05-19 17:57
fwiw, os.Stat(fmt.Sprintf(“%s/a.go”, os.Getenv(“GOPATH”))) does not return error on Windows… maybe “/“ will slip thru ?

arnaud
2016-05-19 17:58
yes, the Windows OS actually understands both forms

muralisr
2016-05-19 17:58
ok

arnaud
2016-05-19 17:58
but mixing the two forms can be a problem

arnaud
2016-05-19 17:59
and for GOPATH for example you're supposed to use ; instead of : as the separator

arnaud
2016-05-19 17:59
that's why go provides os.PathListSeparator too

dmurik
2016-05-19 18:52
@arnaud: @muralisr: Maybe Go's `filepath.Join()` is the standard way to create a path from parts.

dmurik
2016-05-19 18:53
I have a question related to the discussion here: Shouldn't the chaincode programs include all their dependencies in a `vendor` dir?

arnaud
2016-05-19 19:00
@dmurik: I agree with you on filepath.Join()

arnaud
2016-05-19 19:00
this is also the way I would go at it, but as @muralisr points out this hasn't be done to date

arnaud
2016-05-19 19:01
so the question becomes whether we should clean up the code and do that or it's not worth it

cbf
2016-05-19 21:15
thinking about chaincode testing... seems to me that a separate repo for a chaincode better represents what chaincode devs will have used... I could see a proliferation of test chaincode repos... the problem is that then we have to build them all to determine whether a change broke any

cbf
2016-05-19 21:16
might be best to have them off in a separate org for the purpose of housing these examples

arnaud
2016-05-19 21:50
@muralisr: ok, here is one reason to be more careful about how we build filepaths: if you have GOPATH=/opt/gopath/ - note the trailing slash - we end up with things like: 2016/05/19 17:08:29 hashFiles /opt/gopath/src//github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01

arnaud
2016-05-19 21:50
maybe not fatal but I think we can agree it's not pretty either

muralisr
2016-05-19 21:54
@arnaud: agreed. For some reason I thought trailing slashwas stripped off… but if not, we should

arnaud
2016-05-19 21:54
well, I saw there is an if ... for that but it is missing a -1 to actually do the work

arnaud
2016-05-19 21:55
and that's not safe either because if all you had was / you would end up with an empty string

arnaud
2016-05-19 21:55
although GOPATH=/ isn't likely it is easier to call the go functions that will do the right thing no matter what

ghaskins
2016-05-19 22:13
Fwiw: I solved this problem in chaintool already

ghaskins
2016-05-19 22:14
Chaincode packages are isolated from peer GOPATH

arnaud
2016-05-19 22:17
I don't think any of these edge cases are actually going to be ever met in practice given the controlled environment we work in

arnaud
2016-05-19 22:18
I started from an issue that came up in testing environment where it is not as controlled

arnaud
2016-05-19 22:18
issue #866

arnaud
2016-05-19 22:19
but I think we only have to gain from having cleaner code

cbf
2016-05-19 22:20
the absence of tests, the design that makes testing harder, all this needs fixing

arnaud
2016-05-19 22:56
all right peeps, I'm off for the weekend (going to Grand Canyon :-) "see" you on Monday

muralisr
2016-05-19 22:57
@arnaud: have fun!

jonkrone
2016-05-20 01:35
has joined #fabric-dev

rupendradhillon
2016-05-21 04:02
I am trying to set myself up to be able to debug code as it's running (Followed installation steps at https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/install.md): At the moment I have LXDE desktop environment on top of the vagrant box that allows me an IDE to work with. Is that the best approach for this ? or is there a better way to do this with minimal changes to the vagrant image. Also, sorry if this is not the correct channel for this sort of question or has been addressed earlier.

ghaskins
2016-05-22 02:28
hello @rupendradhillon. I’m sure there are many ways to solve the problem, but I have had decent luck using delve (https://github.com/derekparker/delve) and wrote a wiki entry for it here https://github.com/hyperledger/fabric/wiki/Go-Development-Portal#delve

ghaskins
2016-05-22 02:29
This is GDB command-line style debugging though…if IDE breakpoints, etc, are you thing, YMMV

ghaskins
2016-05-22 02:29
feel free to update the wiki with more details if you find something else that works well

goodjoon
2016-05-22 06:16
has joined #fabric-dev

rupendradhillon
2016-05-23 01:20
Thanks @ghaskins

karan
2016-05-23 10:27
has joined #fabric-dev

simon
2016-05-23 17:44
i can't update branches in my github repo, so no useful pull requests from me today

sheehan
2016-05-23 19:47
also was experiencing issues with GitHub earlier today. Seems to be better now

kostas
2016-05-23 19:50

arnaud
2016-05-23 20:49
: what is the "car" platform??

arnaud
2016-05-23 20:49
in fabric/core/chaincode/platforms we have golang and car


ghaskins
2016-05-23 20:52

ghaskins
2016-05-23 20:52
(thanks @sheehan!)

ghaskins
2016-05-23 20:53
but the fact that you needed to ask that means I failed to document it well, heh

ghaskins
2016-05-23 20:53
probably could use a README there or something, will review

arnaud
2016-05-23 20:53
sorry, I'll admit not having looked for the docs

arnaud
2016-05-23 20:54
I just stumbled over it in the code and there was no comment that gave any hints as to what it is

ghaskins
2016-05-23 20:54
I meant I should have documented in the platforms/car tree in fabric

arnaud
2016-05-23 20:54
right, that would be nice

arnaud
2016-05-23 20:54
just a pointer to the doc would probably do

ghaskins
2016-05-23 20:54
yeah, thats what I am thinking

ghaskins
2016-05-23 20:54
will do, thanks

ghaskins
2016-05-23 22:08
@cbf @ramesh As per https://github.com/hyperledger/fabric/pull/1556, do you know if I can manually kick off a build from the latest patch in the PR?

ghaskins
2016-05-23 22:09
I know I can restart the previous run, and I can have @arnaud submit a new patch, but its not clear if I can just ask for a specific branch/sha to rebuild

ramesh
2016-05-23 22:19
as far as I know, we have only above two options to re-run the build

ramesh
2016-05-23 22:20
or we can ask user to submit an empty commit (not recommended)

cbf
2016-05-23 22:29
what @ramesh said is also my understanding

ghaskins
2016-05-23 22:35
ok

arnaud
2016-05-23 23:40
Why do you want to restart the build?

ghaskins
2016-05-23 23:40
See my note in the PR

ghaskins
2016-05-23 23:41
I don't think it will matter, but we were burned once before so decided to check all source mods

arnaud
2016-05-23 23:41
Ok

ghaskins
2016-05-23 23:42
Visual inspection looks fine, so it's probably not necessary

maruthi
2016-05-24 02:06
has joined #fabric-dev

ghaskins
2016-05-24 02:10
@muralisr: regarding PR 1549: out of curiosity, what is gating the conversion to behave?

lexsys
2016-05-24 08:14
has joined #fabric-dev

muralisr
2016-05-24 11:30
@ghaskins: fabric's behave’s framework can only store one chaincode at a time

ghaskins
2016-05-24 11:52
ah, that makes sense, thank you @muralisr

muralisr
2016-05-24 11:54
@jeffgarratt will be able to provide that feature … and when its available I can do the switcheroo

ghaskins
2016-05-24 13:13
@muralisr: travis failure after merge

ghaskins
2016-05-24 13:13
not sure why, it passed within the PR

ghaskins
2016-05-24 13:13
re-running now to see if it was transient

muralisr
2016-05-24 13:13
hmm

muralisr
2016-05-24 13:14
I have half a mind to skip the unit test

muralisr
2016-05-24 13:14
its new function and we know we need a behave test

muralisr
2016-05-24 13:14
if its me, I apologize

ghaskins
2016-05-24 13:14
its unclear

muralisr
2016-05-24 13:14
well, that’s the only new thing

ghaskins
2016-05-24 13:15

ghaskins
2016-05-24 13:15
well, i mean its unclear if its an actual code failure or some fluke

muralisr
2016-05-24 13:15
do you have the old failure by any chance ?

muralisr
2016-05-24 13:15
right. that’s how I understood it :slightly_smiling_face:

ghaskins
2016-05-24 13:15
unforunately it looks like it was overwritten when I restarted the build

muralisr
2016-05-24 13:15
ok

muralisr
2016-05-24 13:16
as an aside .. did you see the conversation on fabric-dev-consensus on timer/crontab ?

ghaskins
2016-05-24 13:33
@muralisr: failed again

muralisr
2016-05-24 13:34
looking


muralisr
2016-05-24 13:34
hmmm… is this failing the unit test ?

muralisr
2016-05-24 13:35
I see the last line says PBFT

ghaskins
2016-05-24 13:35

muralisr
2016-05-24 13:36
looking closer

jonathanlevi
2016-05-24 13:36
has joined #fabric-dev

muralisr
2016-05-24 13:40
let me try updating env and running unit tests in my env

ghaskins
2016-05-24 13:41
ok, i also am testing with the merge reverted to see if it passes again


muralisr
2016-05-24 13:42
ok

ghaskins
2016-05-24 13:46
regarding timer/crontab, ill read the thread when I get back from my run

muralisr
2016-05-24 13:46
ok

muralisr
2016-05-24 13:47
unit test fail on my machine with what appears to be exact failure as seen in travis

muralisr
2016-05-24 13:48
I’m going to revert my chaincode change (sans the unit test … )

muralisr
2016-05-24 13:48
and test again

muralisr
2016-05-24 13:48
I doubt if that is the root cause

ghaskins
2016-05-24 13:48
im guessing there was something that was merged after your PR submission but before your PR was merged that was conflicting

muralisr
2016-05-24 13:48
could be….

muralisr
2016-05-24 13:49
if so reverting my chaincode change should work

ghaskins
2016-05-24 13:49
i double checked, it was passing in the PR itself

muralisr
2016-05-24 13:49
right

sheehan
2016-05-24 13:53
@muralisr: does the unit test you added start a peer?

muralisr
2016-05-24 13:54
@sheehan it does like other unit tests… but note the test hasn;t progressed to chaincode tests yet


muralisr
2016-05-24 13:55
obcpft fails first and the chaincode tests appear to succeed later

sheehan
2016-05-24 13:57
weird. I think writing a unit test that tries to emulate the function test gets us into trouble. Is it possible to just write a unit test that doesn’t test the full end to end function? Then a behave test could added for testing the end to end function when available?

sheehan
2016-05-24 13:58
possibly some mocking is needed or is it just that unit tests cannot be written in that area for some reason?

muralisr
2016-05-24 14:00
right. I was going along that path for a bit with the new chaincode test. the problem was without behave test, a mock up test wouldnt test anything for this (chaincode calling chaincode, member service, etc)

muralisr
2016-05-24 14:04
@ghaskins: after reverting the chaincode change, still fails on pbft


muralisr
2016-05-24 14:16
running obctests in isolation

muralisr
2016-05-24 14:18
fabric/consensus/obcpbft$ go test 1> /tmp/out 2>&1

muralisr
2016-05-24 14:18
same failure

tuand
2016-05-24 14:21
@simon: similar to the unit tests problem you were just dealing with ?

simon
2016-05-24 14:22
unclear what the error is

simon
2016-05-24 14:22
need to see the test that failed

anya
2016-05-24 14:23
has joined #fabric-dev

tuand
2016-05-24 14:23
@muralisr: run go test in the obcpbft dir ?

muralisr
2016-05-24 14:24
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F1B9Q2AR1/out and commented: I get that from “go test” in fabric/consensus/obcpbft

ghaskins
2016-05-24 14:26
@muralisr: my reverted branch did build


ghaskins
2016-05-24 14:26
or at least, it got past the unit-test problem

ghaskins
2016-05-24 14:27
behave result still pending

muralisr
2016-05-24 14:27
its still failing on my branch

muralisr
2016-05-24 14:27
sorry, in in my laptop

ghaskins
2016-05-24 14:28
@sheehan: shall we PR the revert for now until we figure out what went wrong?

simon
2016-05-24 14:28
muralisr: looking at it

muralisr
2016-05-24 14:28
@ghaskins: was the only revert my chaincode change ?

muralisr
2016-05-24 14:29
@simon: thanks

ghaskins
2016-05-24 14:30
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1BBCC14H/-.sh and commented: This is what I ran to revert/fix it

ghaskins
2016-05-24 14:30
(I confirmed on line 6) that the revert seemed to be equivalent to the original PR, at least by visual inspection

muralisr
2016-05-24 14:31
ok

muralisr
2016-05-24 14:31
then I’m not sure what’s happening…

muralisr
2016-05-24 14:31
as far as I can tell the obcpbft tests have no relation to the chaincode changes

ghaskins
2016-05-24 14:32
yeah, its probably just a compound interaction of something

ghaskins
2016-05-24 14:32
the two PRs by themselves were fine

sheehan
2016-05-24 14:32
I would say give Simon a bit of time to finish investigating before deciding to revert

ghaskins
2016-05-24 14:33
ok…ill leave my branch at the ready

tuand
2016-05-24 14:36

simon
2016-05-24 14:37
it's a timing issue

simon
2016-05-24 14:37
tuand: wait, you get the same problem?

tuand
2016-05-24 14:37
no, just saw it in murali's log

simon
2016-05-24 14:37
yea

simon
2016-05-24 14:38
so the thing is that two complaints somehow are reordered, only the newer one is processed, that makes the older request stale

simon
2016-05-24 14:38
and then there is not enough time for the originator to re-submit its now stale request again

simon
2016-05-24 14:38
testing artifact, not a bug

muralisr
2016-05-24 14:39
so that means a bug in the test case because it fails ?

simon
2016-05-24 14:40
the problem is that there are goroutines, timers, race conditions

muralisr
2016-05-24 14:41
is this an artefact of a recent change ?

simon
2016-05-24 14:43
no, all our unit tests are that way

simon
2016-05-24 14:43
for better or worse

simon
2016-05-24 14:44
we need to get rid of all goroutines and replace everything with a linear state machine

muralisr
2016-05-24 14:44
I haven’t seen this failure before…. so assumed some recent change triggered this

simon
2016-05-24 14:44
no, stuff races all the time

simon
2016-05-24 14:44
does it fail repeatedly for you?

muralisr
2016-05-24 14:45
yes

muralisr
2016-05-24 14:45
3 times consecutively today

muralisr
2016-05-24 14:45
let me try once more

simon
2016-05-24 14:45
sorry about that

muralisr
2016-05-24 14:46
not at all

muralisr
2016-05-24 14:46
this is what I do

muralisr
2016-05-24 14:46
cd fabric/consensus/obcpbft

muralisr
2016-05-24 14:46
go test 1>/tmp/out 2>&1

muralisr
2016-05-24 14:46
that’s ok to do ?

tuand
2016-05-24 14:47
that's fine

muralisr
2016-05-24 14:48
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F1BBJJESV/pasted_image_at_2016_05_24_10_47_am.png and commented: failed again… seems repeatable on my laptop at least

simon
2016-05-24 14:49
well the only suggestion is to disable the test

simon
2016-05-24 14:49
this is a combination of various races

simon
2016-05-24 14:51
the problem is:

simon
2016-05-24 14:55
1. replica 2 receives f+1 view-change requests with v=1 2. replica 2's custody times out for req1; replica 2 complains 3. replica 1 (new primary) receives complaint 4. replica 1 receives 2f+1 view-change requests, becomes new primary, sends new-view; clears its complaint store 5. replica 2's custody times out for req2; replica 2 complains 6. replica 1 receives complaint for req2, sends-preprepare 7. req2 gets ordered and committed; req1 is now stale 8. test ends -> req1's custody never expires again so that replica 1 can resubmit the request

tuand
2016-05-24 15:00
can we move the test to behave ? maybe we can control the sequence a bit better there

muralisr
2016-05-24 15:03
I guess I know the answer, but let me ask anyway :slightly_smiling_face: … this seems to happen with the recent change I pulled

muralisr
2016-05-24 15:03
Srinivasans-MBP:fabric muralisr$ git fetch upstream remote: Counting objects: 85, done. remote: Compressing objects: 100% (26/26), done. remote: Total 85 (delta 51), reused 40 (delta 40), pack-reused 19 Unpacking objects: 100% (85/85), done. From https://github.com/hyperledger/fabric c6628c2..e38141f master -> upstream/master Srinivasans-MBP:fabric muralisr$ git merge upstream/master Updating c6628c2..e38141f Fast-forward consensus/helper/handler.go | 145 +------ consensus/obcpbft/complainer.go | 38 +- consensus/obcpbft/custodian/custodian.go | 80 ++-- consensus/obcpbft/custodian/custodian_test.go | 41 +- consensus/obcpbft/mock_utilities_test.go | 30 +- consensus/obcpbft/obc-batch.go | 85 ++-- consensus/obcpbft/obc-batch_test.go | 57 ++- consensus/obcpbft/obc-sieve.go | 10 +- core/chaincode/chaincodetest.yaml | 540 ++++++++++++++++++++++++++ core/chaincode/config.go | 6 +- core/chaincode/exectransaction_test.go | 418 ++++++++++++++------ core/chaincode/handler.go | 43 +- core/rest/rest_api.go | 22 +- 13 files changed, 1136 insertions(+), 379 deletions(-)

muralisr
2016-05-24 15:03
what does the test FAIL signify ?

muralisr
2016-05-24 15:04
can any of the changes above make the timing dependencies more accute ?

muralisr
2016-05-24 15:05
I know this is likely hard to answer but still worth asking I think

simon
2016-05-24 15:05
timing is timing

muralisr
2016-05-24 15:05
and +1 for @tuand suggestion to move this to behave…. but it could fail there too

simon
2016-05-24 15:05
we also fixed some complaints bugs

muralisr
2016-05-24 15:06
fair enough

simon
2016-05-24 15:07
i guess CI and my machine are so slow that this ordering doesn't happen :slightly_smiling_face:

muralisr
2016-05-24 15:07
it failed in CI too today

simon
2016-05-24 15:07
aha

muralisr
2016-05-24 15:08
and was soon after a chaincode-callinc-chaincode fix was pulled

muralisr
2016-05-24 15:09
and wanted to understand if this failure could be because of that

hgabor
2016-05-24 15:10
has joined #fabric-dev

hgabor
2016-05-24 15:10
hello

ghaskins
2016-05-24 15:11
@cbf @sheehan https://github.com/hyperledger/fabric/pull/1527 is ready to merge from my perspective…but should I hold off until we get clarity on 1549 fix/revert situation?

ghaskins
2016-05-24 15:12
hello @hgabor, welcome to fabric-dev

hgabor
2016-05-24 15:12
I ve forked fabric and tried to create some chaincode. is there any preferred way for logging? to log some messages from my chaincode?

ghaskins
2016-05-24 15:12
@hgabor: yes, @bcbrock just added some nice facilities in there recently

sheehan
2016-05-24 15:13
@ghaskins: yes, I don’t want to merge anything else until there is a resolution to the current problem. Will make it easier to back stuff out if needed

ghaskins
2016-05-24 15:13
ill defer to him on the details though, as I havent studied it closely

hgabor
2016-05-24 15:13
thx :slightly_smiling_face:

ghaskins
2016-05-24 15:13
@sheehan: agreed, sounds good

ghaskins
2016-05-24 15:14
will consider merges frozen until we talk again


hgabor
2016-05-24 15:15
I ll check it out, thanks

jonathanlevi
2016-05-24 15:19
--- On a separate topic, I want to run some API change proposition by you guys.

jonathanlevi
2016-05-24 15:19
The REST API has a `GetTransactionCert()` call which allows the caller to specify how many TCerts are required (BTW: as an embedded 'count' parameter). "Underneath", there is a loop calling GetNextTCert() say K times, at the rest_api (.go) level.

jonathanlevi
2016-05-24 15:21
We need to be able to do this more efficiently, and one proposition/option is to add another method, say: `GetNextTCerts( nCerts uint32 )`

jonathanlevi
2016-05-24 15:21

jonathanlevi
2016-05-24 15:23
Another option is that instead of having 2 exposed functions - to rather have just one: `GetNextTCerts( nCerts uint32 )`, returning a slice of TCerts (which can be used to also obtain 1 TCert when needed, as I'd rather not to duplicate logic/implementation). I want to pick your brain, and before diving into this, to make sure that I'm not missing anything...

jonathanlevi
2016-05-24 15:26
======= In other words: Any objections to having a single function call, say: `func (client *clientImpl) GetNextTCerts( nTCerts uint32 ) ( []tCerts, error) ` and change the current calls to `func (client *clientImpl) GetNextTCert() (tCert, error)` accordingly as the new function returns a slice...

jonathanlevi
2016-05-24 15:53
@bcbrock, @binhn, @cbf, @ghaskins, @keithsmith, @sheehan (& ): unless there's any stern objection, I'll put this proposition (also) in a GitHub issue... there are many/several references that will need a change, which is why I'm asking widely.

sheehan
2016-05-24 15:56
@jonathanlevi: so the loop would move to client_impl.go? I’m not that familiar with this code, but it looks like the tcertPool interface only allows fetching one tcert at a time.

sheehan
2016-05-24 15:56
probably @diego_m would be a good person to ask

jonathanlevi
2016-05-24 15:57
So first, I want to remove the logic from the rest_api.go, so that we can reuse this logic, and not have it at the API layer.

jonathanlevi
2016-05-24 15:59
Second, yes, @diego is aware of this (see #890), the client_impl.go will change to reflect (and have) this logic or retrieving multiple TCerts

jonathanlevi
2016-05-24 15:59
Third, while addressing 1 & 2, I am trying not to have an extra functions, but to have only 1.

diego_m
2016-05-24 15:59
Hello Jonathan, let me take a look

anya
2016-05-24 16:00
it’s a good point… i always wondered why the crypto layer was not able to handle the retrieval of multiple TCerts. i support the proposal described above for `func (client *clientImpl) GetNextTCerts( nTCerts uint32 ) ( []tCerts, error)`

jonathanlevi
2016-05-24 16:01
Thank you @anya. I also noticed that it's sometimes confusing that the Handler, has only one cert underneath...

jonathanlevi
2016-05-24 16:01
I'm trying to make it more intuitive, so that the logic is underneath the API.

diego_m
2016-05-24 16:02
Yes, as Anya mentioned that is the idea, to have a REST method to retrieve multiple TCerts at a time, moving that loop to the crypto layer

jonathanlevi
2016-05-24 16:02
@diego_m: would you agree that we can use only one external function for both uses? (a single TCert or more)?

jonathanlevi
2016-05-24 16:03
@diego_m: Awesome!

diego_m
2016-05-24 16:03
be aware that there are two implementations for the TCert pool, one single threaded and one multi threaded, some changes need to be done in the multi-threaded version probably, you can check with @andres since he had to modify it to support attributes

jonathanlevi
2016-05-24 16:04
@diego_m: Yes, noticed that. Thanks.

diego_m
2016-05-24 16:05
Could be only one function but for clarity I would like to have the two functions, one can be constructed on top of the other, I don’t know what @anya thinks about that

jonathanlevi
2016-05-24 16:05
Other than @diego_m's support, any objections for changing the API as proposed above?

jonathanlevi
2016-05-24 16:05
I'd rather have only one function exposed with all the logic.

jonathanlevi
2016-05-24 16:06
Both for a single TCert or more, same call...

anya
2016-05-24 16:08
I think having a single function exposed on the crypto layer to retrieve TCerts is just fine The REST layer will still need to pass a query parameter to specify how many are needed, just as it does today. Though I do know know any specifics regarding the multi-threading that @diego_m is mentioning. So if that introduces some extra complexity in making this work, i think having two separate calls are fine too. If not, one call is more transparent and better IMO.

jonathanlevi
2016-05-24 16:10
Yeah, I'd rather spend the (not too much) extra time to do the 'right' thing.... as this is a core feature of membersrvcs.

jonathanlevi
2016-05-24 16:11
As I mentioned, we can always wrap the single TCert request with a `GetNextTCerts(1)` call

diego_m
2016-05-24 16:11
that is what I was thinking when I mentioned having the two methods

diego_m
2016-05-24 16:13
for the pools check with Andres, he can tell you how complex making changes there could be and probably you can provide additional input since we want to redesign that functionality

jonathanlevi
2016-05-24 16:14
Yes, will check with @andres too, thanks! Yeah, I can tell how painful some these are...

andres
2016-05-24 16:14
has joined #fabric-dev

jonathanlevi
2016-05-24 16:15
Still, any objections (client-sdk-wise), or otherwise, do let me know. In the meantime, I'm putting together a few issues with these...

guglielmo_n
2016-05-24 16:17
has joined #fabric-dev

binhn
2016-05-24 16:18
i would get @adc ’s advice on changes at crypto layer — also whether this function is used by the node.js client sdk @keithsmith

simon
2016-05-24 16:38
@sheehan, @muralisr: i submitted a PR to disable the test for now

arnaud
2016-05-24 16:41
@muralisr: once that fire is out I'd appreciate if you could have a look at the PR I submitted regarding the handling of GOPATH in chaincode handling https://github.com/hyperledger/fabric/pull/1556

muralisr
2016-05-24 16:43
@arnaud: sure thing. definitely before sometime tonight. Will that work ?

arnaud
2016-05-24 16:44
sure, thank you

sheehan
2016-05-24 17:04
@simon: for some reason Travis did not run on your PR. Restarting now

guglielmo_n
2016-05-24 17:26
Hi All. I am trying to run the Asset Management example. I am using the REST API directly. All goes well apparently, until I try a query. And this is what I get: ```{"jsonrpc":"2.0","error":{"code":-32003,"message":"Query failure","data":"Error when querying chaincode: Error:Failed to execute transaction or query(Timeout expired while executing transaction)"},"id":1464109660}``` I think I have my environment set up correctly, as I can execute example02. What is the current status of Asset Management on master? What can I do to track down the cause of the timeout? I am really new to the community, so any help will be greatly appreciated! Thank you.

muralisr
2016-05-24 17:30
@guglielmo_n: two resources (1) peer log and (2) chaincode log

muralisr
2016-05-24 17:30
there are two “asset_manament” tests

guglielmo_n
2016-05-24 17:30
This is the payload for the query: ```{ "jsonrpc": "2.0", "method": "query", "params": { "type": 1, "chaincodeID": { "name": "0ac5a08d42014a017c21d67d52e94635c9d1362215fc29d5f25f9f9bc9c4b2307c56802f257317bef2700715f6a6c050d02dc093bea0e456f7b6e55e4e91601b" }, "ctorMsg": { "function": "query", "args": ["Picasso"] }, "secureContext": "lukas" }, "id": 1464109660``` For context, I am logged in with user 'lukas', and I assigned a "Picasso" asset to user "test_user0"

muralisr
2016-05-24 17:31
which one are you refering to ?

muralisr
2016-05-24 17:32
examples/chaincode/go/asset_management ?

guglielmo_n
2016-05-24 17:32
@muralisr: Going to attach logs! I have deployed this chaincode: http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management

muralisr
2016-05-24 17:32
ok

guglielmo_n
2016-05-24 17:34
vp0.log is quite big (2.8 MB), I'll try to extract the relevant portion. Thanks for offering help, @muralisr

muralisr
2016-05-24 17:35
sure

guglielmo_n
2016-05-24 17:37
```cat vp0.log | grep -v PEER | grep -v PeersMessage > vp0.short.log```

guglielmo_n
2016-05-24 17:37
62K

muralisr
2016-05-24 17:38
well, I think we need the whole log

guglielmo_n
2016-05-24 17:39
okay, will try to find a significant snippet, but intact

muralisr
2016-05-24 17:39
I’d look for (1) errors after deploy or invoke (not just query)

muralisr
2016-05-24 17:40
and (2) docker ps (to see if the chaincode is running)

muralisr
2016-05-24 17:41
and docker logs <chaincode container id>

muralisr
2016-05-24 17:41
ie, if you try and trace the logs after each action hopefully you’ll get the root cause

guglielmo_n
2016-05-24 17:41
I have the "peer node start" container up (only)

guglielmo_n
2016-05-24 17:41
```$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0d104dbdc9f0 mikezaccardo/hyperledger-peer:pbft "peer node start" About an hour ago Up About an hour 0.0.0.0:5000->5000/tcp, 0.0.0.0:30303-30304->30303-30304/tcp, 0.0.0.0:31315->31315/tcp vp0```

muralisr
2016-05-24 17:41
after deploy you should see a container get started

muralisr
2016-05-24 17:42
docker ps -a

guglielmo_n
2016-05-24 17:42
```$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES bd57ffc9a300 dev-vp0-0ac5a08d42014a017c21d67d52e94635c9d1362215fc29d5f25f9f9bc9c4b2307c56802f257317bef2700715f6a6c050d02dc093bea0e456f7b6e55e4e91601b "/opt/gopath/bin/0ac5" 35 minutes ago Exited (2) 34 minutes ago dev-vp0-0ac5a08d42014a017c21d67d52e94635c9d1362215fc29d5f25f9f9bc9c4b2307c56802f257317bef2700715f6a6c050d02dc093bea0e456f7b6e55e4e91601b 0d104dbdc9f0 mikezaccardo/hyperledger-peer:pbft "peer node start" About an hour ago Up About an hour 0.0.0.0:5000->5000/tcp, 0.0.0.0:30303-30304->30303-30304/tcp, 0.0.0.0:31315->31315/tcp vp0```

muralisr
2016-05-24 17:42
docker logs 0ac5a08d42 > /tmp/cc.log

muralisr
2016-05-24 17:43
sorry

muralisr
2016-05-24 17:43
docker logs bd57 > /tmp/cc.lgo

muralisr
2016-05-24 17:44
i’m guessing it exited due to an error and that would help guide to root cause

guglielmo_n
2016-05-24 17:45

guglielmo_n
2016-05-24 17:45
yeah, `index out of range`

muralisr
2016-05-24 17:46
let me check

guglielmo_n
2016-05-24 17:47
thanks!

sjcorbett
2016-05-24 17:47
has joined #fabric-dev

muralisr
2016-05-24 17:50
I’m guessing the array element access in " myLogger.Debug("Query done [% x]", row.Columns[1].GetBytes())” in asset_management.go

muralisr
2016-05-24 17:50
line 278

muralisr
2016-05-24 17:50
can you debug with that ?

guglielmo_n
2016-05-24 17:54
I suppose I could debug it, but as I'm trying to run the examples to understand the big picture, I first wanted to know if it was something I did wrong with my setup. It looks like a bug, correct?

muralisr
2016-05-24 17:55
I’m not sure

muralisr
2016-05-24 17:56
it is on the face of it. but it might be the asset manage,ent code is expecting something

muralisr
2016-05-24 17:56
in other words it _could_ be user error exposing an unwarranted assumption

guglielmo_n
2016-05-24 17:58
okay, so maybe I invoked the chaincode with bad parameters, or something like that, and that exposed an assumption in the code

muralisr
2016-05-24 17:58
sure, something like that

muralisr
2016-05-24 17:58
I think a bit of debug will help figure out where exactly the problem is

guglielmo_n
2016-05-24 17:59
so it's not a bug, as in a bug in the algorithm, but maybe a parameter check is missing somewhere

guglielmo_n
2016-05-24 18:01
in this case should I raise an issue anyway?

guglielmo_n
2016-05-24 18:01
or just a PR if I find the real cause or the missing check?

muralisr
2016-05-24 18:04
once you have more info, by all means!

muralisr
2016-05-24 18:05
just that it maybe easier for you to debug given you have done this once

guglielmo_n
2016-05-24 18:12
Oh I actually still haven't debugged Go code in this context (HL). For my immediate purposes I'll first go on trying other examples, to rule out the possibility that I have set up something in a wrong manner. But I will return to it! Thanks again!

muralisr
2016-05-24 18:13
sure thing. here to help!

david.stark
2016-05-24 19:18
has joined #fabric-dev

andreaturli
2016-05-24 19:55
has joined #fabric-dev

guglielmo_n
2016-05-24 20:45
is there any example of a JSON payload for the REST API with security enabled?

duncanjw
2016-05-25 00:09
has joined #fabric-dev

duncanjw
2016-05-25 00:10
@guglielmo_n: can you share all the operations you performed?

mikezaccardo
2016-05-25 00:41
i may have figured out what’s wrong with @guglielmo_n setup — metadata is missing from his REST requests, specifically the admin certificate

mikezaccardo
2016-05-25 00:42
what is the proper format for metadata in a POST to /chaincode?

mikezaccardo
2016-05-25 01:01
and related: how should a certificate be expressed? i’d like to assign the value of a user’s certificate to “metadata”. can i just paste the value from /registrar/$user/ecert?

mikezaccardo
2016-05-25 01:11
now we might be getting somewhere! ``` { "jsonrpc": "2.0", "method": "deploy", "params": { "type": 1, "chaincodeID":{ "path":"http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management" }, "ctorMsg": { "function":"init" }, "metadata": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlCc0RDQ0FWYWdBd0lCQWdJQkFUQUtCZ2dxaGtqT1BRUURBekF4TVFzd0NRWURWUVFHRXdKVlV6RVVNQklHDQpBMVVFQ2hNTFNIbHdaWEpzWldSblpYSXhEREFLQmdOVkJBTVRBMlZqWVRBZUZ3MHhOakExTWpVd01ESTVOVFZhDQpGdzB4TmpBNE1qTXdNREk1TlRWYU1FQXhDekFKQmdOVkJBWVRBbFZUTVJRd0VnWURWUVFLRXd0SWVYQmxjbXhsDQpaR2RsY2pFYk1Ca0dBMVVFQXd3U2JIVnJZWE5jWW1GdWExOWhYREF3TURBeE1Ga3dFd1lIS29aSXpqMENBUVlJDQpLb1pJemowREFRY0RRZ0FFMS9RVUJYaFp4UzhVczNWbXY1OFI1M2hGU3dWek9sZmxZeXlDazY1RDlBR1A2NThWDQpTSldGYlZLekFYWllhdkFsV3RMdlJ1blNVMzNTbktRYUtwMW1xYU5RTUU0d0RnWURWUjBQQVFIL0JBUURBZ2VBDQpNQXdHQTFVZEV3RUIvd1FDTUFBd0RRWURWUjBPQkFZRUJBRUNBd1F3RHdZRFZSMGpCQWd3Qm9BRUFRSURCREFPDQpCZ1pSQXdRRkJnY0JBZjhFQVRFd0NnWUlLb1pJemowRUF3TURTQUF3UlFJaEFMcjVSem9qWmNhNTVSVTdXZnFHDQo3d1MwcUowMitTOEFpVXJ5cjBqZXNFSmJBaUJGSUI1TFI3YVQ2NVNxQy96b0J3VFJkV2RLNUJFTE1WM3d4bWVKDQphQ0FjN2c9PQ0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==", "secureContext": "lukas" }, "id": 1464023039 } ```

mikezaccardo
2016-05-25 01:11
``` { "jsonrpc": "2.0", "result": { "status": "OK", "message": "d5edee9650db08c02af4737e9990450652e4cf7f803fc8e20c4403c2f67017cd6c5bc85941b5f7ca67d1556d1825871e22a98e4467af6d1fdd8ea1e0d0465ef6" }, "id": 1464023039 } ```

duncanjw
2016-05-25 01:17
@mikezaccardo: cool

guglielmo_n
2016-05-25 07:09
Thanks for figuring this out @mikezaccardo: this is exactly what was missing there!

joseph
2016-05-25 09:35
@mikezaccardo: When I get /registra/jim/ecert, I got a result.

joseph
2016-05-25 09:35
{"OK": "-----BEGIN+CERTIFICATE-----%0AMIIBrTCCAVSgAwIBAgIBATAKBggqhkjOPQQDAzAxMQswCQYDVQQGEwJVUzEUMBIG%0AA1UEChMLSHlwZXJsZWRnZXIxDDAKBgNVBAMTA2VjYTAeFw0xNjA1MjUwOTI2Mjda%0AFw0xNjA4MjMwOTI2MjdaMD4xCzAJBgNVBAYTAlVTMRQwEgYDVQQKEwtIeXBlcmxl%0AZGdlcjEZMBcGA1UEAwwQamltXGJhbmtfYVwwMDAwNDBZMBMGByqGSM49AgEGCCqG%0ASM49AwEHA0IABGH8pkK7SP3gZuVhchWGgcbIPTBX1EDVMBbeNqMLuyHYmZLPj0nj%0AwaLMo2CimHeAMZzVHn4%2BEbvDYie9TLL0vsCjUDBOMA4GA1UdDwEB%2FwQEAwIHgDAM%0ABgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwDgYG%0AUQMEBQYHAQH%2FBAExMAoGCCqGSM49BAMDA0cAMEQCIAPVdoW98j8ub%2FH5gRfxdq2k%0A3u2SrkWPa196d6FOnH2NAiAjm78eke4KTVALnOFOZCtIjLh5GVfJjRtdWu%2FF06Bq%0Aww%3D%3D%0A-----END+CERTIFICATE-----%0A"}

joseph
2016-05-25 09:36
what is metadata for next requests?

joseph
2016-05-25 09:39
we should parse

joseph
2016-05-25 09:39
"-----BEGIN+CERTIFICATE-----%0AMIIBrTCCAVSgAwIBAgIBATAKBggqhkjOPQQDAzAxMQswCQYDVQQGEwJVUzEUMBIG%0AA1UEChMLSHlwZXJsZWRnZXIxDDAKBgNVBAMTA2VjYTAeFw0xNjA1MjUwOTI2Mjda%0AFw0xNjA4MjMwOTI2MjdaMD4xCzAJBgNVBAYTAlVTMRQwEgYDVQQKEwtIeXBlcmxl%0AZGdlcjEZMBcGA1UEAwwQamltXGJhbmtfYVwwMDAwNDBZMBMGByqGSM49AgEGCCqG%0ASM49AwEHA0IABGH8pkK7SP3gZuVhchWGgcbIPTBX1EDVMBbeNqMLuyHYmZLPj0nj%0AwaLMo2CimHeAMZzVHn4%2BEbvDYie9TLL0vsCjUDBOMA4GA1UdDwEB%2FwQEAwIHgDAM%0ABgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwDgYG%0AUQMEBQYHAQH%2FBAExMAoGCCqGSM49BAMDA0cAMEQCIAPVdoW98j8ub%2FH5gRfxdq2k%0A3u2SrkWPa196d6FOnH2NAiAjm78eke4KTVALnOFOZCtIjLh5GVfJjRtdWu%2FF06Bq%0Aww%3D%3D%0A-----END+CERTIFICATE-----%0A"

joseph
2016-05-25 09:39
to encoding base64?

mikezaccardo
2016-05-25 10:10
we’ve actually switched to using the asset management app (https://github.com/hyperledger/fabric/tree/master/examples/chaincode/go/asset_management/app) on a CLI node — this is much easier than trying to DIY with the REST API

joseph
2016-05-25 10:13
@mikezaccardo: how did you produce metadata? Could you please tell it in detail?

joseph
2016-05-25 14:41
@guglielmo_n: what are deployment differences between asset management example and other examples?

arnaud
2016-05-25 15:35
@muralisr: ok, I fixed the GOPATH env set up. I'm glad you caught that. I have to admit not to have thought about that possibility at all

arnaud
2016-05-25 15:36
of course the weird thing in all that is that go doesn't provide Getenv and Setenv outside of the os itself

arnaud
2016-05-25 15:38
my trick was merely to try and find a way to use those rather than having to deal with the basic string based Environ() struct

arnaud
2016-05-25 15:38
oh well

muralisr
2016-05-25 15:41
@arnaud: right. quite with you. I did add one more comment suggesting another change - basically now that we have to use Environ anyway, why a Getenv AND an Environ when just use Environ once upfront ..

arnaud
2016-05-25 15:42
because it still makes the code simpler

arnaud
2016-05-25 15:42
well, I think :slightly_smiling_face:

arnaud
2016-05-25 15:43
my reasoning is that the less code the better

arnaud
2016-05-25 15:44
but I'll understand if you feel differently

muralisr
2016-05-25 15:44
well, in that case, I do :slightly_smiling_face:

arnaud
2016-05-25 15:45
:slightly_smiling_face:

muralisr
2016-05-25 15:46
its not true duplication and I’d actually say that Getenv and Environ is duplicating code at some level (albeit in different areas)

muralisr
2016-05-25 15:46
besides being a tad inefficient because of that

muralisr
2016-05-25 15:47
but given all the other good work in the PR, willing to forgo the point :slightly_smiling_face:

arnaud
2016-05-25 15:50
bah, it's ok, I can go with your preferred way too

ghaskins
2016-05-25 15:50
@arnaud: I didn’t pick up on it either until @muralisr mentioned concurrency

arnaud
2016-05-25 15:50
yeah, I thought I was being smart :wink:

ghaskins
2016-05-25 15:51
I applaud all attempts to utilize existing facilities

arnaud
2016-05-25 15:52
thanks, that was my motivation indeed

muralisr
2016-05-25 15:56
and heavens knows I’m guilty contributing to code duplication … so Im not really one to speak freely on that :slightly_smiling_face: … thanks for catching all that!

arnaud
2016-05-25 16:29
ok @muralisr I made the change and added a comment so that future fools like me know what's up :wink:

muralisr
2016-05-25 16:35
thanks @arnaud, will look soon (and wish I had dollar everytime I had made similar statements…. :slightly_smiling_face: )

arnaud
2016-05-25 16:35
lol

kostas
2016-05-25 17:23
I `make behave-deps` then `make behave`, yet several of the behave scenarios fail ("Error starting container: cannot connect to Docker endpoint") - how would I go about fixing this?

tuand
2016-05-25 17:24
i think the docker port was changed a while back ... make sure your docker compose files have the right endpoint set

ghaskins
2016-05-25 17:26
@kostas: a) do you run in vagrant? b) if so, have you been running the same vagrant-up for a while now?

ghaskins
2016-05-25 17:26
there was a change that went in perhaps about 2 weeks ago that changed the docker port, if you didnt vagrant destroy/up across that update it might fail in that manner

kostas
2016-05-25 17:27
ah that would be it, will retry - thank you both

jonathanlevi
2016-05-25 18:09
--- Hi everyone, I just together this item https://github.com/hyperledger/fabric/issues/1589 regarding testing (in Python, vs. in Golang). Thoughts welcome (either on the issue, here, or in @ramesh's newly opened # channel...). We are working to add many more tests, and wondered what people think about these? In the meantime, I'm off to writing some Behave tests :wink:

jonathanlevi
2016-05-25 18:10
[@cbf, @sheehan, @binhn @joshhus @jeffgarratt et al.]

sheehan
2016-05-25 18:13
@jonathanlevi: Thanks for starting this discussion. I’ll comment in the issue. @cbf has suggested Ginkgo also

arnaud
2016-05-25 23:43
@cbf can we get a new repo created, called fabric-test or something along those lines, so that we can put some test in it that needs to be stored outside the main repo?

tedy
2016-05-26 06:04
has joined #fabric-dev

yacovm
2016-05-26 10:52
Does anyone know what may cause chaincode to run as `docker-containerd-shim d04f6fff014fc974c0f7cfcf874b265d661e316798179051b22dab753d83595c /var/run/docker/libcontainerd/d04f6fff014fc974c0f7cfcf874b265d661e316798179051b22dab753d83595c docker-runc` and not show up in `docker ps` ?

cbf
2016-05-26 12:45
@arnaud: why do the tests need to live independent of the main repository?

ghaskins
2016-05-26 12:47

ghaskins
2016-05-26 12:48
see the comments about the http test

ghaskins
2016-05-26 12:48
(sorry, not sure how to get a link to the comments that are germane here)

ghaskins
2016-05-26 12:49
the summary was that a chaincode needed to be a) accessible via HTTP, and b) not live in hyperledger/fabric

ghaskins
2016-05-26 12:50
its currently implemented pointing to a private github, but might be more prudent to use a HL controlled repo

arnaud
2016-05-26 15:17
@muralisr, @ghaskins so I tried to use a specific version of the chaincode example for my HTTP test but it doesn't work

ghaskins
2016-05-26 15:18
@arnaud: ok, NBD

arnaud
2016-05-26 15:18

ghaskins
2016-05-26 15:18
go is very versioning-unfriendly, so that doesnt surprise me

arnaud
2016-05-26 15:19
you can see for yourself doing a straight go get

arnaud
2016-05-26 15:20
it apparently downloads it alright but then fails to find the package

arnaud
2016-05-26 15:21
$ GOPATH=/opt/gopath/_usercode_/tmp go get http://github.com/lehors/fabric/tree/ca8135b1a0f95127c96478518628a65a377ec123/examples/chaincode/go/chaincode_example01 package http://github.com/lehors/fabric/tree/ca8135b1a0f95127c96478518628a65a377ec123/examples/chaincode/go/chaincode_example01: cannot find package "http://github.com/lehors/fabric/tree/ca8135b1a0f95127c96478518628a65a377ec123/examples/chaincode/go/chaincode_example01" in any of: /opt/go/src/github.com/lehors/fabric/tree/ca8135b1a0f95127c96478518628a65a377ec123/examples/chaincode/go/chaincode_example01 (from $GOROOT) /opt/gopath/_usercode_/tmp/src/github.com/lehors/fabric/tree/ca8135b1a0f95127c96478518628a65a377ec123/examples/chaincode/go/chaincode_example01 (from $GOPATH)

arnaud
2016-05-26 15:22
I can see that it populated /opt/gopath/_usercode_/tmp/

arnaud
2016-05-26 15:22
so the code is there, it just can't find it with the version number in the path

muralisr
2016-05-26 15:24
the above does not work for me either


muralisr
2016-05-26 15:24
but this does


arnaud
2016-05-26 15:25
right

arnaud
2016-05-26 15:25
I wanted to use a specific version in response to Greg's point that otherwise we have no way of knowing which version was used when running the test

muralisr
2016-05-26 15:27
ah ok

arnaud
2016-05-26 15:27
it looks like there is no way to do that with go get

arnaud
2016-05-26 15:37
@muralisr: I'm sorry if I'm just being dense here but why can't we just have gopath set to the temporary directory to do the go get?

arnaud
2016-05-26 15:39
I just did a test and it seems to work

arnaud
2016-05-26 15:41
I set GOPATH to codegopath (//opt/gopath/_usercode_/xxxx)


arnaud
2016-05-26 15:42
because GOPATH doesn't include the Fabric repo, the code is downloaded over HTTP and the test passes

arnaud
2016-05-26 15:45
I guess this only works if the chaincode comes with all the fabric stuff

arnaud
2016-05-26 15:46
which is true in the case of the test but wouldn't in general

muralisr
2016-05-26 15:46
@arnaud: the point was to use code from fabric for dependencies (several goodness in that). It just means that fabric example will already be found in the fabric and won’t be downloaded - which in a way is correct.

muralisr
2016-05-26 15:47
exactly. This is specific to fabric examples used as http://

arnaud
2016-05-26 15:47
I understand why it's not being downloaded

arnaud
2016-05-26 15:48
what exactly is used/needed from what's downloaded with the go get?

arnaud
2016-05-26 15:50
I noticed go get downloads a whole bunch of things, including git files and al

muralisr
2016-05-26 15:53

ghaskins
2016-05-26 15:56
personally, i think trying to support a go-get compatible coordinate is a bad idea in general…i think these issues are just highlighting why

ghaskins
2016-05-26 15:58
on-boarding the code application should be independent of language idiosyncrasy

muralisr
2016-05-26 15:58
well, this issue we run into is specific to attempting to point to http when the chaincode is already in the fabric

ghaskins
2016-05-26 15:59
right, but thats part of what I mean

muralisr
2016-05-26 15:59
ok

muralisr
2016-05-26 15:59
I understand

ghaskins
2016-05-26 16:01
at the expense of sounding like a broken record, its one of the things I solved with chaintool…now Im not saying everyone needs to use chaintool (though I would certainly welcome that), the general concept of packaging could be adopted and then you dont need to worry about the URL or local filesystem path

ghaskins
2016-05-26 16:02
the package is the package, you pull it in (either via URL, filepath, or inline bytes) and build it

ghaskins
2016-05-26 16:02
then it doesnt matter where it came from

muralisr
2016-05-26 16:02
agreed. Its got its advantages for sure

ghaskins
2016-05-26 16:02
all the above problems go awy

ghaskins
2016-05-26 16:03
I realize I am preaching to the choir, heh

muralisr
2016-05-26 16:03
and you can do your own things (application level) - versioning etc

muralisr
2016-05-26 16:03
oh no, not at all

ghaskins
2016-05-26 16:03
precisely

ghaskins
2016-05-26 16:05
i recognize the dilemma though…go is really structured around go-get

ghaskins
2016-05-26 16:05
so you either use it whole heartedly warts and all, or you have to build something on top

ghaskins
2016-05-26 16:09
I wonder if I should create an alternate platform in chaintool that lets someone use the packaging but forgo the code generator

ghaskins
2016-05-26 16:10
so, you still code things exactly the same with your own entry points for Init/Invoke/Query, you don’t have any CCI interfaces nor metadata facilities, but at least you get a unified package

ghaskins
2016-05-26 16:11
(or maybe its just an option on the .golang platform that already exists)

muralisr
2016-05-26 16:21
trying to wrap head around that …. :slightly_smiling_face: I REALLY need to ride some CARs :slightly_smiling_face:

ghaskins
2016-05-26 16:21
heh

ghaskins
2016-05-26 16:22

muralisr
2016-05-26 16:22
one thing though… part of the problem is the mixing of platform and languages

muralisr
2016-05-26 16:22
IMO

muralisr
2016-05-26 16:22
I will

ghaskins
2016-05-26 16:22
not following: can you elaborate?

muralisr
2016-05-26 16:24
both VM (docker) and chaincode (language) use “platform"

muralisr
2016-05-26 16:24
I feel it could be more cleanly separated

ghaskins
2016-05-26 16:24
as in the chaintool definition of platform, or the peer codebase definition ?

muralisr
2016-05-26 16:28
the later

ghaskins
2016-05-26 16:28
ah, yes, that would be a good cleanup

muralisr
2016-05-26 16:28
Its not a clear statement, I agree but something I feel when design/impl

ghaskins
2016-05-26 16:29
though you did a good portion of the groundwork for that with syscc, i thought

arnaud
2016-05-26 16:29
Greg, thanks for the teaser, now I really want to understand what's in your CAR proposal :wink:

muralisr
2016-05-26 16:29
right, syscc forced some of the things to be flushed out.

muralisr
2016-05-26 16:30
but more probably can be done in that direction ?

ghaskins
2016-05-26 16:30
@arnaud: just the concepts presented here: https://github.com/ghaskins/chaintool#typical-workflow

ghaskins
2016-05-26 16:30
that is, developer runs “chaintool package” when they are ready to deploy, and that emits a single .car file (chaincode archive, similar in concept to a .jar)

ghaskins
2016-05-26 16:31
and that single file would be the coordinate that is deployed (either as a URL/fs reference, or inline bytes to the API call)

ghaskins
2016-05-26 16:32
@muralisr: I havent looked at the impl in depth, and im sure theres always room for further tweaking, but my initial impression was you got most of it

ghaskins
2016-05-26 16:33
i guess the java work will help tease anything that remains

muralisr
2016-05-26 16:33
thanks! I think so too :slightly_smiling_face:

muralisr
2016-05-26 16:33
right …exactly my thoughts

ghaskins
2016-05-26 16:33
(assuming we want additional/alternative isolation for JVM

muralisr
2016-05-26 16:33
where does the dependent jar file come from ?

muralisr
2016-05-26 16:34
when we add platforms/java we will feel the burn :slightly_smiling_face:

ghaskins
2016-05-26 16:34
well, if I had my way, it would be in a .car with platform something like “org.hyperledger.chaincode.java” :wink:

muralisr
2016-05-26 16:34
that will certainly have to be an option

ghaskins
2016-05-26 16:35
actually, if I really had my way, it would be .java files in the .car

ghaskins
2016-05-26 16:35
(since I think the contract needs to be reviewable)

ghaskins
2016-05-26 16:35
but that is just me: the CAR concept could support .jars if that is what was desired

muralisr
2016-05-26 16:35
I thought you’ll just generate the java code from the message definition ?

ghaskins
2016-05-26 16:36
well, to be clear I am referring to the contract code itself

muralisr
2016-05-26 16:36
ah I see

muralisr
2016-05-26 16:36
the implementation of the interfaces

ghaskins
2016-05-26 16:36
but yes, if I were to develop a org.hyperledger.chaincode.java platform, I assume I would be generating java code

muralisr
2016-05-26 16:36
behind the interfaces

ghaskins
2016-05-26 16:36
precisely

ghaskins
2016-05-26 16:37
theres no reason we couldnt carry .jars in the .car payload, but I think its ideal to support source deployments and have the peer compile it locally

ghaskins
2016-05-26 16:37
it could certainly be an option and/or an alternate platform to have jar vs source deployments though

ghaskins
2016-05-26 16:38
you dont have quite that flexibility with go since it compiles to native $arch

ghaskins
2016-05-26 16:38
(which is fine by me, since I advocate source deployments anyway)

arnaud
2016-05-26 16:46
one caveat to keep in mind is that some companies are allergic to code being compiled on the fly

arnaud
2016-05-26 16:47
at the first hackathon in Brooklyn I heard something like that from a guy from Citigroup

arnaud
2016-05-26 16:47
their security policies seriously constrain what is allowed

arnaud
2016-05-26 16:48
and if I remember correctly they had restrictions on dynamic compilation

ghaskins
2016-05-26 16:50
well, the beauty is, you can add whatever “platform” you want

ghaskins
2016-05-26 16:50
so you could have “org.acme.shadybytes” platform that only takes LLVM byte codes

ghaskins
2016-05-26 16:51
or whatever you want

ghaskins
2016-05-26 16:52
personally, i find the notion of obscure code execution to be antithetical to blockchain, but thats just me

ghaskins
2016-05-26 16:52
if someone wants to construct their network that way, and people are willing to still use it, more power to them. The fabric will support that

ghaskins
2016-05-26 16:54
my feeling is that notion is better handled via confidentially and hw-enforced enclavement rather than source obscurity

ghaskins
2016-05-26 17:05
reading again, i think I slightly misunderstood you

ghaskins
2016-05-26 17:05
you meant they were concerned about the compilation impact on security, not the code itself being revealed (which is a concern in some circles)

arnaud
2016-05-26 17:05
I hear you it might be a case where some corporate policy has an undesirable consequence

arnaud
2016-05-26 17:06
correct

arnaud
2016-05-26 17:06
I took it as a concern over not controlling the output

ghaskins
2016-05-26 17:06
i still think that is a bit misguided concern…I understand what they are getting at, and for this reason I think DSLs may have some advantages over GPLs here

ghaskins
2016-05-26 17:07
but even for GPLs, I think you have to treat compilation as having similar isolation requirements as runtime and then it should be fine

arnaud
2016-05-26 17:07
they may need to adapt their policies :slightly_smiling_face:

ghaskins
2016-05-26 17:07
yeah, they are misguided

ghaskins
2016-05-26 17:08
obscure code defeats the purpose of a distributed ledger

ghaskins
2016-05-26 17:08
so, then, why use it

arnaud
2016-05-26 17:08
right

ghaskins
2016-05-26 17:08
i do agree we need to design for protecting against malicious/broken code though, and that includes compilation time as well as run time

ghaskins
2016-05-26 17:09
so, be sensitive to? absolutely. prohibit? thats just wrong

arnaud
2016-05-26 17:09
I agree

ghaskins
2016-05-26 17:10
DSLs are a bit in interesting in this regard…you can just remove offensive verbs from the language spec

arner
2016-05-26 19:14
has joined #fabric-dev

jonathanlevi
2016-05-26 19:23
[@binhn: @ghaskins, @sheehan et al.] Can somebody please be kind enough as to create a `membersrvc` tag/label ?

ghaskins
2016-05-26 19:23
looks

ghaskins
2016-05-26 19:24
done

ghaskins
2016-05-26 19:54
@cbf @sheehan https://github.com/hyperledger/fabric/pull/1616 marks a new baseimage release. We really should be tagging these. We didn’t last time around because the process to do so needs to be discussed

ghaskins
2016-05-26 19:55
something like “baseimage-v0.0.10” would be appropriate (assuming when/if that PR goes in)

ghaskins
2016-05-26 19:55
part of the problem, I dont see any way to submit tags as a PR

ghaskins
2016-05-26 19:55
so, the only other way I know to do it would be via git-push directly

ghaskins
2016-05-26 19:56
(which maintainers can technically do, but we don’t generally allow it by policy)

ghaskins
2016-05-26 19:56
so, any thoughts on that?

ghaskins
2016-05-26 19:57
some thoughts: 1) maintainers can push tags, but only tags, and tread lightly to avoid accidents

ghaskins
2016-05-26 19:58
2) people can submit something (perhaps an issue) with a tag, and a maintainer can push it after appropriate agreement, but it shouldnt be the maintainer that requested the tag

ghaskins
2016-05-26 19:58
s/with a tag/with a request for a tag to be created

jphillips
2016-05-26 20:05
has joined #fabric-dev

sheehan
2016-05-26 21:03
: For developers using the Vagrant environment, two pull requests have been merged that require some additional steps. See http://lists.hyperledger.org/pipermail/hyperledger-fabric/2016-May/000011.html for details. Thanks.

bc
2016-05-26 21:50
has joined #fabric-dev

baohua
2016-05-27 01:24
has joined #fabric-dev

simon
2016-05-27 12:59
ghaskins: maybe we should run the unit tests in sequence (-parallel 1)?

cesarev
2016-05-27 13:19
has joined #fabric-dev

charles-cai
2016-05-27 13:31
has joined #fabric-dev

arnaud
2016-05-27 17:12
@sheehan: so, I just stopped my vagrant and on restarting it with vagrant up I get an error: The forwarded port to 5000 is already in use on the host machine.

arnaud
2016-05-27 17:12
what did I miss?

sheehan
2016-05-27 17:52
do you have another service already using 5000 on your host? That’s my guess

arnaud
2016-05-27 17:57
I agree something is there, I have no idea what though

arnaud
2016-05-27 18:12
so the bad news is that it's used by wininit.exe which is part of the Windows OS

sheehan
2016-05-27 18:20
:disappointed:

sheehan
2016-05-27 18:25
so must we pick a different port due to windows?

arnaud
2016-05-27 18:33
maybe this is why it was mapped to a different port in fact

sheehan
2016-05-27 18:41
I think the 3000 is a leftover from the original Vagrantfile template. If we have to move, I’d rather not use 3000 because it conflicts with the common node.js port

arnaud
2016-05-27 18:42
ok, but it looks like there is no hope for 5000 on Windows


arnaud
2016-05-27 18:43
"wininit.exe is a critical system process the Windows requires in order to function."

arnaud
2016-05-27 18:43
"wininit.exe is at the top of the process tree for all of windows services, including svchost.exe."

arnaud
2016-05-27 18:44
sorry for the bad news

sheehan
2016-05-27 18:50
as you’re on a windows system, could you track down a port that does work?

sheehan
2016-05-27 18:51
as a workaround, you can just set the port in Vagrantfile to some working port #

arnaud
2016-05-27 18:51
6000

arnaud
2016-05-27 18:52
yes, that's what I did of course

arnaud
2016-05-27 18:53
apparently Windows uses a bunch of port in the 5000-5999 range

ghaskins
2016-05-27 18:54
If we dont think the product default should be moved, we could probably at least parameterize the Vagrantfile so windows users do not have to edit the file at least

sheehan
2016-05-27 18:54
I’d rather have product default and Vagrant mapping be the same. It clears up a lot of confusion

ghaskins
2016-05-27 18:55
yeah, i agree…just wasnt sure if that would cause heartburn

arnaud
2016-05-27 18:55
I agree, even though I understand it's a pain to change again

ghaskins
2016-05-27 18:55
that is the idea

ghaskins
2016-05-27 18:55
ideal

ghaskins
2016-05-27 18:55
(to have them be the same, i mean)

arnaud
2016-05-27 18:56
and the whole point of using vagrant is so that everybody has the same setup (for better and for worse ;) so having variations like that wouldn't really be fitting

ghaskins
2016-05-27 18:56
ok, thats fine…just throwing an option out there

kostas
2016-05-27 19:54
what does the `key` field in `ColumnDefinition` stand for? it's not immediately obvious, and I can't seem to find the documentation for it https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/chaincode.proto#L33

kostas
2016-05-27 19:55
(and `git blame` points to the mega repo-switch commit that Binh did so I can't figure out who wrote it) thanks!

ghaskins
2016-05-27 19:59
@simon: regarding parallel tests, yeah that is a good goal

ghaskins
2016-05-27 20:00
i suspect we’d need to do some work to get there (for instance, the behave tests fire up docker-compose, so not sure those could be parallelized without re-work). But good idea in general


sheehan
2016-05-27 20:11
There’s an open issue for documentation there https://github.com/hyperledger/fabric/issues/1504

kostas
2016-05-27 20:12
right, I found out about this protobuf via the chaincode shim as well

kostas
2016-05-27 20:13
thx for the info :+1:

jyellick
2016-05-27 20:28
@muralisr: Was considering opening an issue, but wanted to do a little sanity checking first. When we do a deploy transaction, we're including the entire contents of a docker image in it?

ghaskins
2016-05-27 20:32
@jyellick: Id have to double check, but I dont _think_ that is true

ghaskins
2016-05-27 20:32
the image is 1G plus

ghaskins
2016-05-27 20:33
i think its something based on the source…let me look

ghaskins
2016-05-27 20:33
i refactored that code a while back, that doesnt sound familar

jyellick
2016-05-27 20:33
Okay, that sounded wrong to me, but just heard it elsewhere

jyellick
2016-05-27 20:34
Still, I have heard of chaincode deploy transactions that are 200+MB

jyellick
2016-05-27 20:35
And I'm a little concerned about the fact that there doesn't seem to be any upper limit on the size of a deploy transaction

sheehan
2016-05-27 20:36
It’s including the entire $GOPATH/src/github.com/hyperledger/fabric path. It is broken currently

jyellick
2016-05-27 20:36
Yes, I opened up https://github.com/hyperledger/fabric/issues/1417 a while back, because I got bit by that, I suspect I'm not the only one

sheehan
2016-05-27 20:36
problem is that it’s often including a bunch of binaries under that

ghaskins
2016-05-27 20:36
yeah, i think sheehan has it right…its somewhere north of “just the source” but south of “the entire dockerimage

jyellick
2016-05-27 20:36
But I'm more concerned about no limit on the size of deploys

sheehan
2016-05-27 20:36
@anya is working on a temporary fix

jyellick
2016-05-27 20:37
If I send a 6GB deploy into the system

ghaskins
2016-05-27 20:37
agreed we need to police that

jyellick
2016-05-27 20:37
It will more or less deadlock things under a protocol like PBFT

jyellick
2016-05-27 20:37
(Because messages will take so so long, no reasonable timeout will handle it)

sheehan
2016-05-27 20:37
yes, should probably be a setting under core.yaml

anya
2016-05-27 20:37
well, it’s not quite as big as 6BG at the moment… but it’s about 50Mb

jyellick
2016-05-27 20:38
I'm imagining a mistake, or malicious request

sheehan
2016-05-27 20:38
though often you want your web server to block giant POSTs before it even gets to the app

jyellick
2016-05-27 20:39
gRPC is great in that it orders the messages on our chat interface, but if one peer goes to send another that 6GB transaction

jyellick
2016-05-27 20:39
Then it's going to delay all messages on that stream for however long it takes the network to send it.

ghaskins
2016-05-27 20:40
the way i see it, if we had a CAR or CAR-like concept, that would be the maximum sized object that is sent around the network

ghaskins
2016-05-27 20:40
in the case of example02, that is about 2.3k


ghaskins
2016-05-27 20:40
each VP would reconstitute the environment from that, rather than try to pass the GOPATH/dockerimage around along with it

ghaskins
2016-05-27 20:41
(also note that this could be further reduced to a URL + SHA

ghaskins
2016-05-27 20:41
but I digress..the basic concept is we dont need to send data that could be derived locally

jyellick
2016-05-27 20:41
+1 on this, I dislike the idea of imposing arbitrary restrictions on the complexity of the applications (by limiting the size of the application), some other vehicle for delivering the chaincode which is a fixed size would be great

ghaskins
2016-05-27 20:42
to be clear, this proposal I mention would still be variable…but it be would minimalist in terms of content, compressed, and optionally indirect

kostas
2016-05-27 20:42
on a tangentially-related issue, what's the plan on how long an execution is supposed to take?

kostas
2016-05-27 20:43
any plans to place an upper limit there?

ghaskins
2016-05-27 20:43
@kostas: I think we have to

jyellick
2016-05-27 20:43
But if you could deploy a chaincode of arbitrary complexity within a few KB, then we would not be limiting developers by restricting deploys to... 10K, say.

ghaskins
2016-05-27 20:43
I envision a ulimit like facility, configured perhaps in yaml

ghaskins
2016-05-27 20:43
@jyellick: agreed

ghaskins
2016-05-27 20:43
upper limit should be set for sure

muralisr
2016-05-27 20:43
if I had a dollar for every time I wanted to trim the size of the targz …. :wink:

ghaskins
2016-05-27 20:43
i misunderstood you, thought you were saying they would all have same size

ghaskins
2016-05-27 20:44
(in that link I provided, its the “Archive Size” that would impact the wire

jyellick
2016-05-27 20:44
Ah, sorry yes, I wasn't clear

jyellick
2016-05-27 20:46
So, perhaps to deliver the symptom a little late in the discussion, if anyone tries to deploy a chaincode that is 'too big' today, then PBFT fails in interesting ways (especially by constantly 'changing view' [electing a new leader]) because it seems like no one is sending messages, because the deploy takes too long to deliver. This can be mitigated by turning up timeouts, but trying to set timeouts for messages which could range from 2k to 2GB isn't practical.

kostas
2016-05-27 20:46
is that addressed to me? (it can be answer to both questions)

ghaskins
2016-05-27 20:47
@kostas: it was directed at @jyellick though I do agree with you that execution upper limit is important too

ghaskins
2016-05-27 20:48
for execution, something like “ulimit” should be a knob…for deploy size, max deployment size should be option

ghaskins
2016-05-27 20:48
not sure if 10k is big enough to accommodate all foreseeable applications, but I dont think its much bigger than that either

ghaskins
2016-05-27 20:48
50k perhaps?

ghaskins
2016-05-27 20:49
certainly not 50M, not even 1M

ghaskins
2016-05-27 20:49
I included multiple compression options in the spec so the one that achieves highest size efficiency may be selected on a case-by-case basis

ghaskins
2016-05-27 20:50
(though in my testing, gzip seemed to do the best job with the text-oriented source

ghaskins
2016-05-27 20:51
(I contemplated adding a feature that would try each algorithm to see which gives the best results each time the package is created, but right now you have to explictly select or opt for gzip by default

jyellick
2016-05-27 20:53
Yes, 10K, 50K, 500K, I think these are all viable. I think we're fine having timeouts handle a couple orders of magnitude in expected size, but going from a few KB up to a few GB is hard to handle.

ghaskins
2016-05-27 21:02
i cant even imagine how it would work, heh

sheehan
2016-05-27 22:15
back to the port discussion, 6000 is used by X11. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers If we pick any 000 as the default port we’ll likely have some collisions. Do we just go with something less memorable?

arnaud
2016-05-27 22:15
666? :wink:

sheehan
2016-05-27 22:15
haha

sheehan
2016-05-27 22:15
I was going to propose 6689. First 4 digit number in the bitcoin genesis block hash

arnaud
2016-05-27 22:16
I'm ashamed I forgot 6000 is used by X11

arnaud
2016-05-27 22:16
given that I worked at the X Consortium

arnaud
2016-05-27 22:17
how about the last 4 digits of your social security #? :smile:

arnaud
2016-05-27 22:17
at least one of us will remember!

sheehan
2016-05-27 22:17
lol

kostas
2016-05-29 02:04
@bcbrock: what's the average execution time for `make stress2s`? looking for an order of magnitude here, gross estimates will do

kostas
2016-05-29 02:04
(it's been running for an hour now on my MBP)

simon
2016-05-30 09:24
@ghaskins: I was asking about running the unit tests *not* in parallel :slightly_smiling_face:

ghaskins
2016-05-30 11:55
@simon: oh! completely misunderstood you. I didn’t think we did, though?

simon
2016-05-30 11:56
they run in parallel by default

ghaskins
2016-05-30 12:21
I just read the opposite, they only run in parallel if you annotate them as compatible and use the —parallelize flag, neither of which I thought we did

ghaskins
2016-05-30 12:22

ghaskins
2016-05-30 12:23
(see “Parallelizing Tests” about 2/3rds down

ghaskins
2016-05-30 12:23
you think its the opposite?

bcbrock
2016-05-30 16:55
@kostas `make stress2s` takes less than 1 minute on an x86 server after the clients start. This is the only part of the test that is not covered by a timeout. I would be very interested to find out what state the clients are in. I’m effectively calling ‘wait’ on the client subprocesses - so if the job hasn’t finished the client subprocesses have not terminated. Maybe take a look at the log files in your $BUSYWORK_HOME.

bcbrock
2016-05-30 17:01
@ghaskins @simon We’ve had to fix bugs related to tests running in parallel and colliding over TCP ports. This is from `go help testflag`

bcbrock
2016-05-30 17:01
`-parallel n Allow parallel execution of test functions that call t.Parallel. The value of this flag is the maximum number of tests to run simultaneously; by default, it is set to the value of GOMAXPROCS. Note that -parallel only applies within a single test binary. The 'go test' command may run tests for different packages in parallel as well, according to the setting of the -p flag (see 'go help build’).`

simon
2016-05-30 17:01
yes

ghaskins
2016-05-30 17:19
Ah, i see. I interpreted the blog entry as it was completely opt in

ghaskins
2016-05-30 17:20
I was trying to see if there was any opportunities to make the tests complete faster

yingfeng
2016-05-31 02:52
has joined #fabric-dev

slowtokyo
2016-05-31 10:44
has joined #fabric-dev

ghaskins
2016-05-31 11:44
@bcbrock: reading your post again, it still seems like it might be opt in, no?

ghaskins
2016-05-31 11:44
"Allow parallel execution of test functions that call t.Parallel"

ghaskins
2016-05-31 11:44
that sounds like it’s only a candidate if it calls t.Parallel

ghaskins
2016-05-31 11:44
explicitly, i mean

ghaskins
2016-05-31 11:45
the confusing part is the note about the default

simon
2016-05-31 11:46
ah!

simon
2016-05-31 11:46
then i don't know

ghaskins
2016-05-31 12:23
@jeffgarratt: question about behave test names

ghaskins
2016-05-31 12:23
i just ran a full sweep and saw this;

ghaskins
2016-05-31 12:23

ghaskins
2016-05-31 12:24
In an attempt to diagnose I tried to re-run just the failing test like this:

ghaskins
2016-05-31 12:24

ghaskins
2016-05-31 12:24
however, it doesn’t appear that it ran the same (feature:577 vs feature:11)

ghaskins
2016-05-31 12:24
any advice?

tuand
2016-05-31 12:33
greg, I think the 577 in this case is the line number ... try -n "peers using TLS"

ghaskins
2016-05-31 12:35

ghaskins
2016-05-31 12:36
same basic result

simon
2016-05-31 12:40
doesn't it skip them?

tuand
2016-05-31 12:48

tuand
2016-05-31 12:49
was that a typo ? `peer using TLS ` instead of `peers using TLS`

bcbrock
2016-05-31 13:00
@ghaskins My reading of the docs. and some blogs is that yes, `t.Parallel` is an opt in that would have to be added to each test within a package that was safe to run in parallel with other tests.

ghaskins
2016-05-31 13:04
Ok, that's how I read it too. But IIUC you are saying that appears to not be the case?

simon
2016-05-31 13:04
i thought tests ran in parallel

simon
2016-05-31 13:04
but it seems not

bcbrock
2016-05-31 13:05
I believe that tests from different packages run in parallel, I’ve seen it

bcbrock
2016-05-31 13:05
on `top`

simon
2016-05-31 13:05
oooh

bcbrock
2016-05-31 13:05
“Someone” should add `t.Parallel` to our tests to make them run faster

bcbrock
2016-05-31 13:05
(in theory)

simon
2016-05-31 13:06
do they run slowly?

simon
2016-05-31 13:06
i think behave is the big slow thing

bcbrock
2016-05-31 13:06
The Go tests are pretty slow too. Note that in both cases the culprit is Docker

simon
2016-05-31 13:07
creating containers or building stuff in the container?

ghaskins
2016-05-31 13:07
Yes, please elaborate

bcbrock
2016-05-31 13:08
Chaincode deployment is excrutiatingly slow, and so is building containers in the container-building tests

ghaskins
2016-05-31 13:08
Ah, gotcha. I'm working on a PR that might improve some of that

bcbrock
2016-05-31 13:08
My interest is piqued! What is the plan?

ghaskins
2016-05-31 13:09
Well for one I've moved the image creation out of go-test and switched go-build to go-install

simon
2016-05-31 13:10
ah cool

ghaskins
2016-05-31 13:10
Install is much faster to rebuild by a factor of 10x

simon
2016-05-31 13:10
i didn't have time to do that

ghaskins
2016-05-31 13:10
(If nothing has changed)

simon
2016-05-31 13:10
do you use the result of go-install to gauge whether to rebuild the image?

ghaskins
2016-05-31 13:11
I'm mobile now, but I'll send you a preview of the patches in a bit

simon
2016-05-31 13:11
okay

ghaskins
2016-05-31 13:11
Yes

ghaskins
2016-05-31 13:11
It all does intelligent rebuild avoidance now

bcbrock
2016-05-31 13:12
Will this alleviate the chaincode deployment overhead?

ghaskins
2016-05-31 13:22
it should help

muralisr
2016-05-31 13:24
at the risk of stating the obvious :slightly_smiling_face: … tests can be parallel only if things such as ports and database folders don’t collide. For example chaincode tests use a “temp” db and a non-default port 40303 (I think)

muralisr
2016-05-31 13:24
not hard to make unique though

ghaskins
2016-05-31 13:26
@muralisr: yeah, i understood…i was merely exploring the _how_ at this point…i had come to the conclusion that go-test supports it via opt-in, but then was confused by some of the comments earlier that perhaps we already are running parallel


ghaskins
2016-05-31 13:27
one of the next steps will be to introduce “hyperledger/fabric-chaincode-base” and move some of the optimizations into that

ghaskins
2016-05-31 13:27
and take the writeGopathSrc out of the golang code

muralisr
2016-05-31 13:29
great … and apologize for stating the obvious!

ghaskins
2016-05-31 13:29
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1CV6QPNK/-.sh and commented: @simon: you can see the first invocation builds the image, and the second one detects that nothing needs to be done.

ghaskins
2016-05-31 13:30
@muralisr: not at all, good to make sure we are all on the same page

ghaskins
2016-05-31 13:30
@simon: what i still need to work out is to do something like volume mount the $GOPATH/pkg dir so I can reuse the cache…it greatly speeds up the build

jeffgarratt
2016-05-31 13:34
@ghaskins: did you resolve your problem of running the behave test?

ghaskins
2016-05-31 13:37
@jeffgarratt: no, still not sure how to target the one that is failing

ghaskins
2016-05-31 13:38
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1CTUR02X/-.sh and commented: @simon:

ghaskins
2016-05-31 13:39
first build, 32s, second build, optimized-out, touch one file, third build 9s (because of cache)

ghaskins
2016-05-31 13:40
(if nothing changed, it takes about 3s if you force make to rebuild it, which is why I said 10x (3 vs 32)

ghaskins
2016-05-31 13:40
but practically speaking, its probably more like the 9 vs 32

ghaskins
2016-05-31 13:40
(though that is still pretty good)

ghaskins
2016-05-31 13:41
unfortunately the *-image targets do not (yet) benefit from the $GOPATH/pkg cache, as they start with a fresh docker environment each time

ghaskins
2016-05-31 13:41
but I am working on that

ghaskins
2016-05-31 13:42
im my original design, I was injecting the ./build/bin/peer binary into the container rather than building it natively…that was really fast but I was worried it wouldnt result in portability

ghaskins
2016-05-31 13:42
so I backed away from that design

simon
2016-05-31 14:42
i think injecting the binary makes a lot of sense

simon
2016-05-31 14:46
this yaml config business is a monster

simon
2016-05-31 14:46
i think we need something better than viper

cbf
2016-05-31 15:44
anaconda?

simon
2016-05-31 15:46
there are other configuration solutions (that don't use yaml)

simon
2016-05-31 15:46
which verify all spelling, etc.

ghaskins
2016-05-31 15:46
@simon: at first I thought so to, as I can take advantage of the go-install acceleration and make-prereq optimizations…but then I realized, i am assuming that the host and docker are compatible

simon
2016-05-31 15:47
which parse directly into a struct, or behave like flags

ghaskins
2016-05-31 15:47
in vagrant they are, but there are no guarantees :wink:

simon
2016-05-31 15:47
ghaskins: but they are for most people

ghaskins
2016-05-31 15:47
for instance, the host could have a different version of golang or libc, and the binary might not work

simon
2016-05-31 15:47
ghaskins: oh.

simon
2016-05-31 15:47
but the binary should be static

ghaskins
2016-05-31 15:48
thats a misnomer

ghaskins
2016-05-31 15:48

ghaskins
2016-05-31 15:49
probably because golang packages are sort of handled in a static manner

ghaskins
2016-05-31 15:49
but theres still “the rest of the world” including all the stuff we explicitly cgo compile like rocksdb

ghaskins
2016-05-31 15:49
and stuff that golang implicitly depends on, like libc and vdso

ghaskins
2016-05-31 15:50
my guess: 99.999% of the time, I could build the binary on the host and inject it and it would work perfectly fine

ghaskins
2016-05-31 15:50
its the %0.0001 im worried about, heh

ghaskins
2016-05-31 15:50
figured “get it right first and optimize later"

ghaskins
2016-05-31 15:51
if people always build from vagrant, there is no issue since we lockstep vagrant+docker

ghaskins
2016-05-31 15:51
but as we have seen, that isn’t always the case so its a dangerous assumption that I am trying to break us free of

jeffgarratt
2016-05-31 16:21
@ghaskins: if the TLS entry is the one your interested, try this: behave -k --tags=@TLS

ghaskins
2016-05-31 18:21
thanks @jeffgarratt ill give that a shot

ghaskins
2016-05-31 19:45
@bcbrock: do you have a test in busywork that measures the chaincode deployment rate?

jeffgarratt
2016-05-31 19:48
@ghaskins: you can view the chaincode deployment rate with the behave tests for the deploy transactions

jeffgarratt
2016-05-31 19:49
though this may not be exactly the information your looking for

ghaskins
2016-05-31 19:49
ok, ill try that, thanks

yingfeng
2016-06-01 01:03
anyone who could help to fix this issue ? https://github.com/hyperledger/fabric/issues/1627 I think there might exist one situation to lead to this dead lock: if the chaincode shim could not return, the lock of chaincode handler might block further requests.

muralisr
2016-06-01 01:41
@yingfeng: I’m looking at it

muralisr
2016-06-01 01:42
the stack trace from your stress shows goroutines waiting on Lock but so far I have not found a “deadlock"

muralisr
2016-06-01 01:44
I will be recreating with concurrent queries… will post on the issue as soon as I have something (or have more questions)

muralisr
2016-06-01 01:49
@yingfeng: can you expand on _if the chaincode shim could not return, the lock of chaincode handler might block further requests_ please ?

yingfeng
2016-06-01 02:00
@muralisr: thank you~ My suspection is: there is a single global lock within handler: type Handler struct { sync.RWMutex ... } And for each chaincode request, within the `exec` body, there are a series of places calling `Lock()`,say: func (handler *Handler) sendExecuteMessage{ createTxContext serialSend deleteTxContext } Each of the above three methods will have to call the `Lock` sequentially. If `serialSend` would be blocked due to some reason, then other requests would be blocked by the global lock within `Handler` struct. This is my suspection..

muralisr
2016-06-01 02:02
but then we’ll see serialSend on the peer’s stack...

muralisr
2016-06-01 02:02
I didn’t see that in yours

yingfeng
2016-06-01 02:04
could you reproduct it in your local environment? it's pretty easy..

muralisr
2016-06-01 02:04
yes

muralisr
2016-06-01 02:04
that’s what I’m going to do

yingfeng
2016-06-01 02:38
Why `handler.Lock()` is required within the body of `func (handler *Handler) serialSend(msg *pb.ChaincodeMessage)` ? It's just a gRPC call. When I remove this lock operation, fabric corrupted without trace dumped, and these are the error logs: ``` 02:07:28.504 [rest] ProcessChaincode -> INFO 2db19 REST successfully query chaincode: {"jsonrpc":"2.0","error":{"code":-32003,"message":"Query failure","data":"Error when querying chaincode: Error:Failed to execute transaction or query(Timeout expired while executing transaction)"},"id":5} 02:07:28.504 [rest] processChaincodeInvokeOrQuery -> ERRO 2db1b Error when querying chaincode: Error:Failed to execute transaction or query(Timeout expired while executing transaction) 02:07:28.532 [rest] processChaincodeInvokeOrQuery -> ERRO 2db1d Error when querying chaincode: Error:Failed to execute transaction or query(Timeout expired while executing transaction) ```

muralisr
2016-06-01 02:50
trying to understand _fabric corrupted without trace dumped, _ ...

yingfeng
2016-06-01 02:55
just commenting the lock.. ``` func (handler *Handler) serialSend(msg *pb.ChaincodeMessage) error { //handler.Lock() //defer handler.Unlock() ```

muralisr
2016-06-01 02:55
ok...

muralisr
2016-06-01 02:56
are you saying the same test case does not “hang” but completes with a timeout ?

yingfeng
2016-06-01 02:57
yes..

yingfeng
2016-06-01 02:57
and the fabric quit directly

muralisr
2016-06-01 02:58
the “./peer node start” process quit ?

yingfeng
2016-06-01 02:58
yes

muralisr
2016-06-01 02:58
what’s your ulimit -a ?

yingfeng
2016-06-01 02:59
``` core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 256493 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 256493 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ```

muralisr
2016-06-01 03:00
do you know how many concurrent queries you are running ?

yingfeng
2016-06-01 03:01
i set 2000 users within the jmeter. and the peak tps is around 800.

muralisr
2016-06-01 03:02
ok

muralisr
2016-06-01 03:03
I think the Lock is not necessary (probably something historical)

muralisr
2016-06-01 03:04
but i think we are running into some system issues

muralisr
2016-06-01 03:04
I’d have thought socket (open files) or memory limit

muralisr
2016-06-01 03:04
but they seem plent

gengjh
2016-06-01 03:06
I think we need more detail logs for debugging

muralisr
2016-06-01 03:07
@yingfeng: was able to recreate

gengjh
2016-06-01 03:07
@yingfeng: It’s better you enable the debug level and try your test again if it can be reproduced easily

muralisr
2016-06-01 03:07
@gengjh: perhaps… but given that we can recreate easily, we can create logs

muralisr
2016-06-01 03:08
@gengjh: I think its been narrowed sufficiently

yingfeng
2016-06-01 03:09
@gengjh: the log level is set to debug already. it could be reproduced easily..

gengjh
2016-06-01 03:16
I believe you are using the latest code, right? In our env, we are still running the code 1 month ago, we had tried 1000 tps performance test. BTW, how many vp nodes you have?

yingfeng
2016-06-01 03:19
yeah, i am using the latest code. I just setup single peer node for stress testing. If the number of jmeter clients is not that large, say 1000, the system could work with a peak tps of 2000, while when I enlarge the client number to 2000, the system would be hung easily, just a few seconds could make it happen every time.

yingfeng
2016-06-01 03:20
since the claimed overall TPS of fabric is 100K according to github documents...

gengjh
2016-06-01 03:30
:slightly_smiling_face:, I believe to achieve the 100K TPS commitment, should run fabric on more powerful hardware. on x86, we still have a lot of enhancement on the todo list. @muralisr do you have any benchmark report for our reference.

yingfeng
2016-06-01 03:35
I perform the stress testing on server, with Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz,64G Memory, and CentOS 7.2, although jmeter and fabric run together on single machine

muralisr
2016-06-01 03:37
@yingfeng: I suspect a limit of some sort (possibly on the chaincode container side)…. I’ll keep investigating this. But 2 points

muralisr
2016-06-01 03:37
1) the serialSend lock is unnecessary and is possibly clouding the issue

muralisr
2016-06-01 03:37
2) could you try your test running chaincode in dev mode

muralisr
2016-06-01 03:38
where we have better control of system limits via ulimit

yingfeng
2016-06-01 03:38
okay, i will test it in dev mode and let you know

muralisr
2016-06-01 03:38
it’ll be interesting to compare

muralisr
2016-06-01 03:38
I will try too but I have to rig up the env

yingfeng
2016-06-01 03:56
@muralisr: I've just tried under dev mode. I removed the lock within `serialSend`, and perform the testing, the chaincode process quit without core dump, while the peer node process remains alive. Here are the outputs: ``` 11:53:28.425 [shim] DEBU : [7b4d539d]Query completed. Sending QUERY_COMPLETED 11:53:28.425 [shim] DEBU : [5b1052ba]GetState received payload RESPONSE 11:53:28.425 [shim] DEBU : [e2e396dd]Received message QUERY from shim 11:53:28.425 [shim] DEBU : [e2e396dd]Handling ChaincodeMessage of type: QUERY(state:ready) 11:53:28.425 [shim] DEBU : [24eac5e5]Sending GET_STATE 11:53:28.425 [shim] DEBU : [37edd00d]GetState received payload RESPONSE 11:53:28.425 [shim] ERRO : Received error from server: rpc error: code = 13 desc = "grpc: proto: protos.ChaincodeSecurityContext: illegal tag 0 (wire type 0)", ending chaincode stream Error starting Simple chaincode: rpc error: code = 13 desc = "grpc: proto: protos.ChaincodeSecurityContext: illegal tag 0 (wire type 0)"bjs0-3a4:root ~/codebase/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 $ ```

muralisr
2016-06-01 04:04
thanks @yingfeng

muralisr
2016-06-01 04:04
let me check something

yingfeng
2016-06-01 04:04
thank you~..

muralisr
2016-06-01 04:06
do you have the peer log when running in peer mode (with the serialSend lock commented out)

muralisr
2016-06-01 04:06
wonder if there’s a "grpc server exited with error:” there

muralisr
2016-06-01 04:11
actually … just realized something… I think we may need that lock after all for serialization

muralisr
2016-06-01 04:11
I need to check something else for that

muralisr
2016-06-01 04:12
but even if we do, it probably does not have to be the handler lock but a “transport serialization lock”)

muralisr
2016-06-01 04:14
the corruption could be because of the non-serialization (hence the name “serialSend”)

yingfeng
2016-06-01 04:18
I saw some peer outputs perhaps related to the issue you mentioned above: ``` [36m12:16:44.781 [dockercontroller] stopInternal -> DEBU 31c32fESC[0m Stop container dev-jdoe-mycc(Post http://unix.sock/containers/dev-jdoe-mycc/stop?t=0: dial unix /var/run/docker.sock: socket: too many open files) ESC[36m12:16:44.781 [dockercontroller] stopInternal -> DEBU 31c330ESC[0m Kill container dev-jdoe-mycc (Post http://unix.sock/containers/dev-jdoe-mycc/kill: dial unix /var/run/docker.sock: socket: too many open files) ```

muralisr
2016-06-01 04:18
ok

muralisr
2016-06-01 04:20
I added another lock to the handler called transportLock and used that in serialSend

muralisr
2016-06-01 04:20
i still see the problem

muralisr
2016-06-01 04:20
which now cannot be because of the common lock

muralisr
2016-06-01 04:21
can you try that in the “dev” env test ?

yingfeng
2016-06-01 04:22
yeah, sure


muralisr
2016-06-01 04:22
and


muralisr
2016-06-01 04:22
thanks much

muralisr
2016-06-01 04:31
I’m going to turn in for today….will check back later. thanks for all the help, @yingfeng

yingfeng
2016-06-01 04:31
@muralisr: I've run the stress test for 5 minutes already, it seems stable right now..

muralisr
2016-06-01 04:31
interesting

muralisr
2016-06-01 04:32
so it’ll be interesting if you can run in dev with the old lock

muralisr
2016-06-01 04:32
that would complete the matric

muralisr
2016-06-01 04:32
matrix

muralisr
2016-06-01 04:33
so I suspect resource issues with possible interference with using one lock (clouding the dynamics)

yingfeng
2016-06-01 04:34
the qps currently is pretty low, only around 80, and the cpu percentage is very low. Perhaps the resource confliction is of many places..

muralisr
2016-06-01 04:35
yes

muralisr
2016-06-01 04:35
possibly

muralisr
2016-06-01 04:36
well, wish you a good day for now

yingfeng
2016-06-01 04:36
thank you @muralisr :smile:

muralisr
2016-06-01 04:36
thank you too!

yingfeng
2016-06-01 08:17
Hi, for this issue https://github.com/hyperledger/fabric/issues/1602 where I use `calico` as the SDN solution. It reappears after I change to latest commits... If I setup two peers, then only peer1 could get success response to queries.

ghaskins
2016-06-01 16:14
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1DASJ43E/-.sh and commented: @jeffgarratt: Thank you for the tip on isolating the test. I consistently see this test failure in my branch so I am fairly certain its legit. Do you have any advice on how to dig in further? I was trying do so something like "docker-compose -f docker-compose-2-tls-basic.yml start” but nothing is happening and I dont understand why.

ghaskins
2016-06-01 16:14
or maybe the fact that nothing is happening _is_ the hint, heh

ghaskins
2016-06-01 16:17
@jeffgarratt: nm, I needed “compose .. up” not “compose .. start"

jeffgarratt
2016-06-01 17:02
@ghaskins: couple of ways. You can set the doNotDecompose tag on the test, in this way you can run the test and then debug the issues with log viewing

ghaskins
2016-06-01 17:03
ah, that probably would have worked, good idea

jeffgarratt
2016-06-01 17:03
in general, look at the command that was used for docker up. You can then reuse this to kill the system and do it again

jeffgarratt
2016-06-01 17:03
I generally do the following: set the DoNotDecompose tag and run the test.

ghaskins
2016-06-01 17:03
i was able to find the issue once I learned the raw docker-compose incantation

jeffgarratt
2016-06-01 17:04
Then use the docker-compose -f <docker-compoisefile> logs

ghaskins
2016-06-01 17:04
so just add “—tag=@DoNotDecompose” ?

jeffgarratt
2016-06-01 17:04
no, you uncomment the DoNotDecompose tag on the scenario

ghaskins
2016-06-01 17:05
ah, got it

jeffgarratt
2016-06-01 17:05
adding the tag to the scenario

jeffgarratt
2016-06-01 17:05
make sure to re-comment as to not screw up other scenarios when running more than one

ghaskins
2016-06-01 17:05
roger

jeffgarratt
2016-06-01 17:05
as the docker system will NOT be torn down for that scenario, and may screw up subsequent one

jeffgarratt
2016-06-01 17:05
:slightly_smiling_face:

jeffgarratt
2016-06-01 17:06
I also find the following useful for finding specfic errors after running. docker-compose -f docker-compose-4-consensus-batch.yml logs 2>&1 | grep -i err

sheehan
2016-06-01 19:21
has anyone here ever used http://codeclimate.com? If so, is it useful and something we should consider?

arnaud
2016-06-01 20:59
hi all, I've had a branch with a small fix to issue-1309 that has been sitting in my repo for a while and I'm not completely sure what to do with it so I figured I would ask here for input

arnaud
2016-06-01 21:01
the discussion on the issue led to asking whether we should use something else than Viper or use some kind of yaml validator but I haven't seen anything really appealing to me on that front

arnaud
2016-06-01 21:02
so, I'm tempted to submit a PR that does fix the obvious problem I raised with this issue and nothing else but even then I'm not completely sure what the right behavior is

arnaud
2016-06-01 21:03
namely, when a configuration error is found, @simon suggested the program should stop with an error rather than simply emit an error message and continue, is that agreeable to all?

arnaud
2016-06-01 21:04
is calling panic what should be done then?

arnaud
2016-06-01 21:04
I'd appreciate any feedback, thanks

sheehan
2016-06-01 21:58
+1 for panic over error and continue. I guess ideally they would all be verified and cached at startup

arnaud
2016-06-01 22:43
that would require all the logic to be put in one place though, I don't know whether this is practical

arnaud
2016-06-01 23:04
I'll got ahead and submit my PR which I think would be an improvement from where we currently are no matter what

arnaud
2016-06-01 23:04
more can always be done later on

arnaud
2016-06-01 23:46
please, review PR 1679 and comment as needed

chenhua
2016-06-02 04:06
has joined #fabric-dev

ghaskins
2016-06-02 13:21
@simon @bcbrock pleased to announce I was able to get the build logic sorted so that we have full build avoidance/intelligence now: https://github.com/hyperledger/fabric/compare/master...ghaskins:make-enhancement-preview

ghaskins
2016-06-02 13:22
@simon: it dawned on me that I could get the best of both worlds….native-docker builds AND $GOPATH/pkg acceleration

ghaskins
2016-06-02 13:22
im just wrapping up some local testing and will PR this hopefully today

simon
2016-06-02 13:23
cool!

ghaskins
2016-06-02 13:23
(though we are down a maintainer this week with @sheehan out, so it might have a longer acceptance cycle than typical)

simon
2016-06-02 13:23
@jeffgarratt: you around?

jeffgarratt
2016-06-02 13:28
@simon: Im here :slightly_smiling_face:

simon
2016-06-02 13:28
yey!

simon
2016-06-02 13:29

simon
2016-06-02 13:29
jeffgarratt: basically we need to stop blocking when a peer takes too long to receive messages

simon
2016-06-02 13:30
jeffgarratt: right now broadcast waits for all sends to be done, but that doesn't work if one peer is byzantine and does not accept data

simon
2016-06-02 13:31
jeffgarratt: now, this we could work around, but we also need to make sure that we don't buffer data unboundedly

simon
2016-06-02 13:31
jeffgarratt: so i figure we should drop the connection/context if that peer is slow

simon
2016-06-02 13:32
the problem is that chatstreams can be either client or server streams, and you close them in different ways (awkward in any case)

jeffgarratt
2016-06-02 13:34
We can make some modifications to the handler that allow certain error conditions to close the stream

simon
2016-06-02 13:34
yea, but how?

jeffgarratt
2016-06-02 13:34
I had discussed with @jyellick a change to the handleMessage return to include a boolean of whether the stream should be closed.

jeffgarratt
2016-06-02 13:35
in this way, the handler can determine.

simon
2016-06-02 13:35
well that's not the issue here

simon
2016-06-02 13:35
how can the handler close the stream in the first place?

jeffgarratt
2016-06-02 13:35
Failure at the moment

jeffgarratt
2016-06-02 13:36
but discovery would more than likely re-establish the stream

simon
2016-06-02 13:36
yea i didn't find a way to close the connection

simon
2016-06-02 13:36
re-establish is fine

jeffgarratt
2016-06-02 13:37
k, so closing the stream from either side would be sufficient?

simon
2016-06-02 13:37
either side needs to be able to close the stream, i'd say

jeffgarratt
2016-06-02 13:37
k, think we can accommodate this fairly simply

simon
2016-06-02 13:37
great, because i didn't figure out a way

jeffgarratt
2016-06-02 13:38
is the above issue the one we could do this work under?

simon
2016-06-02 13:38
the client side could use a cancelable context

simon
2016-06-02 13:38
but the server side can't

simon
2016-06-02 13:38
however the server side can call .Close() on the serverconnection

simon
2016-06-02 13:38
yea, i think the issue is the right place to coordinate

jeffgarratt
2016-06-02 13:38
k

jeffgarratt
2016-06-02 13:39
need to wrap up a bit of stuff first, will then jump into it

simon
2016-06-02 13:39
i didn't mean to dump this on you

simon
2016-06-02 13:40
i tried figuring out myself, but it is unclear to me how we can cancel/close the connection

simon
2016-06-02 13:40
or stream

ghaskins
2016-06-02 14:00
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1DK8NN6S/-.sh and commented: Anyone else having trouble with ubuntu repos today?

ghaskins
2016-06-02 14:00
opps, sorry, http://dockerproject.org repos

ghaskins
2016-06-02 15:28
seems to have resolved itself now

yacovm
2016-06-02 15:37
how do I stop a travis build?

yacovm
2016-06-02 15:37
can anyone stop 830 please?

ghaskins
2016-06-02 15:39
i can do it (I think)

ghaskins
2016-06-02 15:40
canceled

yacovm
2016-06-02 15:40
I see, thanks a lot

pmullaney
2016-06-02 19:58
has joined #fabric-dev

hgabor
2016-06-03 07:46
hey

hgabor
2016-06-03 07:46
I am just checking this fabric api

hgabor
2016-06-03 07:46
I mean fabric SDK sorry

hgabor
2016-06-03 07:47
is anybody familiar with that?

hgabor
2016-06-03 07:47
maybe this is not the best channel for this but... :slightly_smiling_face:

satheesh
2016-06-03 15:41
has joined #fabric-dev

ghaskins
2016-06-03 19:41
@jyellick: ping

ghaskins
2016-06-03 19:42
@anya: @keithsmith ping

anya
2016-06-03 19:46
yes, @keithsmith and myself are working on this. Please check out the README.md here: https://github.com/hyperledger/fabric/tree/master/sdk/node I will be putting in more commits relating to this shortly, to get the deployment in network mode working. that will complete the base functionality of the node.js sdk, allowing to produce a minimal sample application in Node.js. if you have specific questions, let me know.

ghaskins
2016-06-03 19:48
@anya: there was a thread the other day about building the deploy transaction, but I can no longer recall where it was taking place


ghaskins
2016-06-03 19:48
thank you very much, will comment there so its attached

anya
2016-06-03 19:49
this discussion is ongoing, but i have the basic version of deploy working per my comment on that thread

ghaskins
2016-06-03 19:50
cool, I was going to mention I discovered something interesting that I am not sure you are aware of

ghaskins
2016-06-03 19:52
ill comment in the issue though

ghaskins
2016-06-03 20:50
@anya: @muralisr

ghaskins
2016-06-03 20:51
we were both just talking about the WriteGopathSrc() mods, Murali was asking to fast-track the fix from PR 1708, but it seems @anya might have a similar, possibly better patch

ghaskins
2016-06-03 20:53
(seems we both had the same idea at the same time, but her patch description sounds like it might be more flexible than mine

anya
2016-06-03 20:54
let me stash some work and push out this change so you can take a look. hold on.

ghaskins
2016-06-03 20:54
ok

ghaskins
2016-06-03 20:56
have to step away for a few: kid-with-a-splinter emergency :wink:

muralisr
2016-06-03 20:56
oh no

ghaskins
2016-06-03 21:02
all better, heh

muralisr
2016-06-03 21:14
“splinter” as in broken bone ?

ghaskins
2016-06-03 21:15
no no, wood splinter in thumb in my 2 year old

kostas
2016-06-04 16:17
@bcbrock: FWIW, I destroyed my vagrant setup, rebuilt it from scratch and `make stress2s` still won't complete (I let it run for several hours; I have a last-gen MBP). the `stderr` outputs of VPs 0 to 2 just shows them attempting to stop an unfired idle timer, but VP3 complains about an expired custody and executes a stale request, indicating a bug (it basically hits this line: https://github.com/hyperledger/fabric/blob/7ba04d1c8418b0dbc5e6842d0b42b1fa0b6e136f/consensus/obcpbft/obc-sieve.go#L711). I'm interested in the `busywork` tool as it'll allow us to stress tests consensus, but I'm curious as to why it fails on my machine and doesn't on yours.

babakkia
2016-06-05 12:57
has joined #fabric-dev

fjk
2016-06-06 06:39
Is it possible to connect individual Laptops having hyper ledger on them? So that i can create a network with them. Any links with the steps?

mcrafols
2016-06-06 07:24
@fjk: it's possible

mcrafols
2016-06-06 07:24
you can start VP outside the docker image (but inside vagrant)

mcrafols
2016-06-06 07:25
and if you are able to ping one laptop from another

mcrafols
2016-06-06 07:25
the ports in vagrant are already forwarded

mcrafols
2016-06-06 07:25
and when you start the other nodes

fjk
2016-06-06 07:25
ohh great...actually have built it outside vagrant on two individual laptops

mcrafols
2016-06-06 07:25
you should set the root ip address to where you laptop is

mcrafols
2016-06-06 07:26
well that should be the same

mcrafols
2016-06-06 07:26
with vagrant is just easier because its is just doing node start

fjk
2016-06-06 07:29
how outside the docker image?

mcrafols
2016-06-06 07:39
./peer node start

mcrafols
2016-06-06 07:40
and configuring the core.yaml file

fjk
2016-06-06 07:40
great, i'l give it a shot..hope it works

hgabor
2016-06-06 09:06
how can I make the behave not decompose the docker containers after a test?

hgabor
2016-06-06 09:07
maybe I ve got it: one has to use the doNotDecompose tag

kostas
2016-06-06 09:12
@hgabor: yes ^^

pcen
2016-06-06 09:59
has joined #fabric-dev

hgabor
2016-06-06 10:00
another question how can it happen that the fabric code inside Docker container of behave tests differs from the code outside (I mean in my repo)

satheesh
2016-06-06 14:30
Anybody has experience generating go code from .proto files ?

satheesh
2016-06-06 14:31
After generating the go code by running `protoc --go_out=plugins=grpc:. *.proto`, the build fails with the following error

satheesh
2016-06-06 14:31
`make peer`


bcbrock
2016-06-06 15:02
@kostas I seldom use Vagrant, I’ll try Vagrant this afternoon when I get to the and let you know what I see.

ghaskins
2016-06-06 15:03
@hgabor: the docker images are built from the host source, so they should at least start out the same…however, if you subsequently change/pull the code I suppose its possible that you have stale docker images

ghaskins
2016-06-06 15:04
@satheesh: not sure this will help you, but I would suggest using “make protos” as opposed to trying to run it by hand (unless I misunderstood your workflow)

ghaskins
2016-06-06 15:04
@satheesh: are you running that command under vagrant?

satheesh
2016-06-06 15:05
@ghaskins: I am running it on my local ubuntu box. And its the same in vagrant too, I had to install protobuf since its not provided in the vagrant image

satheesh
2016-06-06 15:06
@ghaskins: `make protos` calls the script `devenv/compile_protos.sh`

ghaskins
2016-06-06 15:06
@satheesh: something sounds off…the vagrant image should indeed have protobuf

ghaskins
2016-06-06 15:06
yes, understood

ghaskins
2016-06-06 15:06
but you implied you were running protoc directly

satheesh
2016-06-06 15:07
Yes, it runs the same command on the suggestion from @muralisr

ghaskins
2016-06-06 15:08
my guess is you installed an incompatible version of protobuf

ghaskins
2016-06-06 15:08
can you clarify on the problem you saw within vagrant regarding protobuf tools missing?

ghaskins
2016-06-06 15:09
ok, thats fine…my only concern with running protoc vs the script/make is you’ll not get them all

satheesh
2016-06-06 15:09

ghaskins
2016-06-06 15:09
try: “make protos"

satheesh
2016-06-06 15:09
@ghaskins: ok I will give it a go

ghaskins
2016-06-06 15:10
hmm, just noticed protos is not correctly dependent on gotools

muralisr
2016-06-06 15:10
@ghaskins: wonder if its possible something failed during vagrant setup ?

ghaskins
2016-06-06 15:10
so, as a workaround, do “make gotools protos"

ghaskins
2016-06-06 15:10
@muralisr: no, i think he probably did a “make clean” at one point, and I didnt correctly express the dependency in the protos target

ghaskins
2016-06-06 15:11
(make clean will blow away the protoc-gen-go plugin

muralisr
2016-06-06 15:11
I see

muralisr
2016-06-06 15:11
let me try it

satheesh
2016-06-06 15:11
Do I need to destroy my vagrant before doing it ?

ghaskins
2016-06-06 15:11
the correct thing is minimally that the protos target should ensure the plugin is available

ghaskins
2016-06-06 15:11
@satheesh: nope, just “make gotools protos"

ghaskins
2016-06-06 15:12
ill file an issue to correct the protos target

ghaskins
2016-06-06 15:12
@muralisr: to your point, its always possible vagrant didnt provision correctly too

muralisr
2016-06-06 15:13
@satheesh: can confirm @ghaskins s suspicion

muralisr
2016-06-06 15:13
vagrant@hyperledger-devenv:v0.0.10-0a467f8:/opt/gopath/src/github.com/hyperledger/fabric/protos$ !protoc protoc --go_out=plugins=grpc:. *.proto protoc-gen-go: program not found or is not executable --go_out: protoc-gen-go: Plugin failed with status code 1.

ghaskins
2016-06-06 15:13
we need to have a better way to inform/detect if vagrant didnt finish correctly, because “vagrant ssh” will still work even if the provisioner didnt make it very far at all

ghaskins
2016-06-06 15:13
but that said, I think this is a more basic problem

ghaskins
2016-06-06 15:14
@muralisr: i guess we should review whether “make clean” should blow away the go-tools….

ghaskins
2016-06-06 15:15
im a bit torn…we built them, so it seems prudent to clean them up when asked

ghaskins
2016-06-06 15:15
but it could be a candidate for “make dist-clean” as opposed to the more general clean

muralisr
2016-06-06 15:15
that sounds better to me…

ghaskins
2016-06-06 15:15
but that said, the real bug is I missed the proper dependency declaration

muralisr
2016-06-06 15:16
the intent of make clean is usullay “remove the dynamic stuff I created"

ghaskins
2016-06-06 15:16
yeah, i think I like that too

ghaskins
2016-06-06 15:16
yeah, well thats why i was torn…we _do_ create those binaries now

ghaskins
2016-06-06 15:16
but, they are third party

ghaskins
2016-06-06 15:16
so, I can see the argument either way

muralisr
2016-06-06 15:16
true

ghaskins
2016-06-06 15:16
i think dist-clean makes sense…if you want a real clean-slate / big hammer, use dist-clean

ghaskins
2016-06-06 15:17
otherwise, “make clean” will work just at the fabric level

muralisr
2016-06-06 15:17
maybe we need a make dist to be symmetric with make dist-clean ?

satheesh
2016-06-06 15:17
`make clean` did it.

ghaskins
2016-06-06 15:17
we could, but not sure what it would entail

ghaskins
2016-06-06 15:18
@satheesh: ok, so for a workaround for now, just use “make gotools protos” and I _think_ that will work

ghaskins
2016-06-06 15:18
at least within vagrant

muralisr
2016-06-06 15:18
it did for me

muralisr
2016-06-06 15:18
within vagrant

ghaskins
2016-06-06 15:18
it _might_ work outside of vagrant too but would be dependent on your environment

satheesh
2016-06-06 15:20
Thanks @ghaskins and @muralisr

ghaskins
2016-06-06 15:21
as an aside, I eventually plan to dissolve the compile_protos.sh script and have the makefile manage those tasks directly, so best to be in the habit of using the makefile now rather than by-hand

philippe
2016-06-06 15:28
has joined #fabric-dev

bcbrock
2016-06-06 19:54
@kostas: Just ran on my Macbook Pro with a fresh Vagrant build. The busywork stress2s fails with the issue 1091 signature:

bcbrock
2016-06-06 19:54
driver: Client 0 is subprocess 27157 with seed 4172233751 driver: Waiting (indefinitely) for subprocesses to complete fabricLogger:ERROR: 0.0.0.0:55744 @ block 4252: Error getting transactions: missing value to go with key fabricLogger:ERROR: Full HTTP token dump fabricLogger:ERROR: HTTP 'ncode' = '200'

bcbrock
2016-06-06 19:55
A request for a block is coming back as NULL.

bcbrock
2016-06-06 19:56
Whether consensus “works” seems to be system dependent (probably related to goroutine timing?)

bcbrock
2016-06-06 19:57
I have also noted that on my POWER server, stress2s “usually” works in SMT4 and SMT8 modes, but not SMT2

bcbrock
2016-06-06 19:58
Actually, as Jason points out the issue may not be with consensus but with the chain/blocks API

jyellick
2016-06-06 22:09
@bcbrock: If you are seeing blocks that correctly chain together (ie, contain a `PreviousBlockHash` that matches the hash of the previous block), then as much as it pains me, I believe it most likely consensus. I'm unable to reproduce with busywork on my laptop, so although I know the logs are likely huge, if you could put them somewhere I could take a look, it would be helpful.

bcbrock
2016-06-06 22:11
@jyellick I’m seeing both null blocks and otherwise well-formed blocks that have no transactions. I’ll try to get traces of the well-formed blocks (assuming I have enough GSA quota)

jyellick
2016-06-06 22:17
The one's with no transactions would be of most interest to me. The NULL ones seem less likely to be related to consensus, though obviously still need to be tracked down.

gengjh
2016-06-07 00:57
@sheehan, pls help to review that https://github.com/hyperledger/fabric/pull/1683

nits7sid
2016-06-07 10:26
Hi....I am trying to build outside vagrant but i am getting error after running make peer or make membersrvc could not determine kind of name for C.rocksdb_restore_options_t make: *** [membersrvc] Error 2.. How to resolve it?

hgabor
2016-06-07 11:00
hi all

hgabor
2016-06-07 11:01
are there any unit tests for the event sender system?


nits7sid
2016-06-07 11:23
yeah

ghaskins
2016-06-07 11:25
have you run the ./scripts/provision/host.sh ?

ghaskins
2016-06-07 11:25
(assuming you are using ubuntu/trusty, that is

nits7sid
2016-06-07 11:27
no i havent tried running that

ghaskins
2016-06-07 11:31
what steps from the guide have you done, and for the ones that you skipped, why?

ghaskins
2016-06-07 11:31
for instance, i assumed you installed rocksdb?

nits7sid
2016-06-07 11:39
yea i have installed rocksdb

ghaskins
2016-06-07 11:41
sorry i have not seen that error

cbruguera
2016-06-07 13:14
has joined #fabric-dev

starsheriff
2016-06-07 13:32
has joined #fabric-dev

dianfu
2016-06-07 13:38
has joined #fabric-dev

randy
2016-06-07 19:10
has joined #fabric-dev

simon
2016-06-08 12:40
lol go, what a shitshow

simon
2016-06-08 14:32
go channels are ridiculously complicated

simon
2016-06-08 14:32
it's a bad primitive

mpage
2016-06-08 14:33
has joined #fabric-dev

crow15
2016-06-08 16:20
has joined #fabric-dev

ghaskins
2016-06-08 22:04
@binhn: @anya @muralisr I root caused the CI failure of 1720, its because the core.yaml structures are not available in the unit test and therefore the fileExt slice is empty

ghaskins
2016-06-08 22:05
(not sure why we thought local UTs were passing before, because I was able to reproduce the same error as CI this time around

ghaskins
2016-06-08 22:05
anyway, my recommended course of action is to go back to 1708 approach (hard-coded const-map) but add the extra files that 1720 was including (.json, .c, .h)

ghaskins
2016-06-08 22:05
but I am open to suggestion

muralisr
2016-06-08 23:30
@ghaskins: I second the hardcoding approach

muralisr
2016-06-08 23:31
really this is something internal and no value in exposing it in yaml IMO

ghaskins
2016-06-08 23:33
I liked the yaml in the sense that if there was ever an “oppps” in the field, someone could fix it

ghaskins
2016-06-08 23:34
but I dont think its a big deal, more trouble than it was worth as it turns out

ghaskins
2016-06-08 23:34
but who knew

muralisr
2016-06-08 23:34
true….

baqer
2016-06-09 05:54
has joined #fabric-dev

lexsys
2016-06-09 06:43
Hi! What does configuration parameter `cli.address` do? I tried to find line in the codebase it is used but found nothing Comment says it is used for callbacks from chaincodes, but aren't chaincodes running on validation hosts, not on client hosts?

anya
2016-06-09 11:02
@ghaskins: @muralisr I do think it’s important to have the value be configurable actually for PR #1720. The whole point of putting it into the .yaml was to make sure that a person who is trying to deploy a random chaincode package on the peer could do that without having to edit our source code. What if they are reading some dependent information in their chaincode that is stored into a file that they need and we are filtering it out during the packaging? Then this requires them to edit writer.go to make that happen. That seems a bit ridiculous… I’d like to ask @jeffgarratt what he thinks before we proceed with the hard coding approach. @jeffgarratt do you know how to make the .yaml parameters be accessible from the UTs? somehow my PR (linked below) is failing CI because as @ghaskins points out, the UTs are not able to extract the info from the .yaml with line: viper.GetStringSlice("chaincode.filetypes”). Though I also had all the UTs pass locally, which is really confusing to me. https://github.com/hyperledger/fabric/pull/1720

anya
2016-06-09 11:15
Also, we do use viper.ReadInConfig and viper.GetString and viper.SetDefault in other Go unit test files. Look at api_test.go or ledger/pkg_test.go which references testutil.SetupTestConfig(). That has all kinds of http://viper.xxx usage in there relative to the .yaml file. So I am wondering how that could possibly be true that in writer.go during UTs these methods do not work. I do recall that for me locally they passed with no issues.

muralisr
2016-06-09 11:26
@anya : note that every file that’s part of the chaincode itself is (and always has been) included

muralisr
2016-06-09 11:27
the filtering in WriteGopathSrc just collects files that is part of the peer NOT in the user’s chaincode path

ghaskins
2016-06-09 12:18
@anya: I would tend to agree with you which is why I was pushing for 1720 too….I think I am “ok” with not having it in the YAML only because I recognize that the “real right way” is to use the go-list tricks, at which point the 1708/1720 solution goes away anyway

ghaskins
2016-06-09 12:19
so, because I view it as a stop-gap, I am ok with the more hardcoded approach….that said, if the yaml access issue is trivial, that is fine too

shubhamvrkr
2016-06-09 12:27
when i start a peer i get x 509 certificate invalid or expired ....need help

anya
2016-06-09 12:51
@ghaskins: I will touch base with Jeff today and let you know what he says. If there is just something simple that we are missing regarding the .yaml access, great. If not, we will go with your approach.

hgabor
2016-06-09 15:58
can anybody tell me where imports such as viper come from at build time?

ghaskins
2016-06-09 16:09

ghaskins
2016-06-09 16:09
you can use “go list” to ask the resolver specifically, when in doubt

ghaskins
2016-06-09 16:10
I think something like ‘go list -f “{{ .Imports }}” http://github.com/hyperledger/fabric/peer | grep viper’ would do it

binhn
2016-06-09 16:34
@anya: @ghaskins @muralisr since the files that we filter making up the peer-go-chaincode-base, so in a way, we know the files at build time, and I would vote for hardcode them in 1708 and move on

ghaskins
2016-06-09 16:36
@binhn: ok.. @muralisr makes a good point also: the only thing the filter impacts are the deps/transitive-deps of the chaincode which by their nature cannot be anything outside of the “Source Files” section here: https://golang.org/cmd/go/#hdr-List_packages

ghaskins
2016-06-09 16:36
because, even if the chaincode itself packages non-go files, that mechanism to bring those files in is discrete from this one

ghaskins
2016-06-09 16:37
so, we could arguably include some of those others (CXX, M, S, Swig) but I think it would be overkill

ghaskins
2016-06-09 16:38
i can update the hardcoded filter to at least replicate the superset in 1720, and fix that other busywork/Makefile thing I mentioned and update the PR

binhn
2016-06-09 16:38
ok, thanks

ghaskins
2016-06-09 16:40
@hgabor: btw: I gave you the wrong template parameters

ghaskins
2016-06-09 16:40
you want .Deps, not .Imports

ghaskins
2016-06-09 16:40
.Imports will only give explicit imports, not transitives

simon
2016-06-09 17:37
how do i call system chaincode?

ghaskins
2016-06-09 17:40
same as any chaincode, except it acts kind of like devmode in the sense that it has a name instead of a hash

ghaskins
2016-06-09 17:41
so, for example ‘-n sample_syscc'

ghaskins
2016-06-09 17:41
otherwise, it acts the same

ghaskins
2016-06-09 19:38
@cbf: ping

cbf
2016-06-09 19:39
@ghaskins: pong

ghaskins
2016-06-09 19:39
hey, I just saw your 1772 go by

cbf
2016-06-09 19:39
I think I neglected to add dependencies to vendored stuff

cbf
2016-06-09 19:39
silly me

ghaskins
2016-06-09 19:40
not sure what problem you were seeing, but if its just a matter of ensuring at tool is installed grep “golint” in the makefile

ghaskins
2016-06-09 19:40
ah, ok, if its a vendoring thing that is something different

ghaskins
2016-06-09 19:41
nm, i thought you might have hit an issue where something like golint/gofmt binary wasnt available

cbf
2016-06-09 19:41
no, ginkgo and gomega

cbf
2016-06-09 19:41
do I just add the source trees to the vendor tree?

ghaskins
2016-06-09 19:41
(not familar, but I am assuming from the contexts they are import-only facilities

ghaskins
2016-06-09 19:42
honestly, i am not sure as @sheehan handled all that, but I think the “govendor” tool is involved somehow

ghaskins
2016-06-09 19:42
i think he put something in the doc about this

cbf
2016-06-09 19:43
looking


ghaskins
2016-06-09 19:45
related to my earlier comment about golint, if you find you dont have “govendor”, just do “make gotools"

ghaskins
2016-06-09 19:45
that should install it

cbf
2016-06-09 19:45
yeah found it

cbf
2016-06-09 19:45
thanks!

cbf
2016-06-09 20:32
oh, it gets weirder

cbf
2016-06-09 20:33
apparently you cannot vendor ginkgo and gomega

cbf
2016-06-09 20:33
so we will need to add them to the development environment

cbf
2016-06-09 20:33
ugh

ghaskins
2016-06-09 20:36
oh really? any idea why?

ghaskins
2016-06-09 20:36
(not that I am an expert on what can and can’t be vendored

cbf
2016-06-09 20:48
I can ask Onsi (the guy who wrote it) but I just confirmed

cbf
2016-06-09 20:48
so we need to go get foo as a function of the vagrant file, I think

cbf
2016-06-09 20:48
yes?

ghaskins
2016-06-09 20:57
it might be better if we can do it as a function of the makefile

ghaskins
2016-06-09 20:57
then it wont depend on vagrant

ghaskins
2016-06-09 20:57
but worst case, yes

ghaskins
2016-06-09 20:57
first question: do you care to pin it to a specific version?

ghaskins
2016-06-09 21:00
actually if all you need is the current, I think we can just add “go get” in the makefile and that should pull in all deps

jonathanlevi
2016-06-09 21:00
go get should be fine

jonathanlevi
2016-06-09 21:00
(It's a pretty stable suite). Again, don't quote me on that, in case hell breaks loose... but yeah.

ghaskins
2016-06-09 21:01
ok, this should be really straight forward then…would be best if it can go in behind #1774

ghaskins
2016-06-09 21:02

ghaskins
2016-06-09 21:03
The method I know would be to add a similar “go get” above the “go install”, though there may be a slicker way to handle that

ghaskins
2016-06-09 21:03
(for instance, perhaps “go install” can be configured to pull missing deps…TBD

ghaskins
2016-06-09 21:04
is this only pulled in during unit-tests?


cbf
2016-06-09 21:41
I’ll be adding the makefile changes in a push of a new commit

cbf
2016-06-09 21:41
just running the tests now from scratch

hgabor
2016-06-10 07:45
does anybody know how can I adjust peer configuration using environment variables?

ghaskins
2016-06-10 10:53
a yaml property like “foo.bar” can be overridden in the environment by doing CORE_FOO_BAR

ghaskins
2016-06-10 10:53
@hgabor:

hgabor
2016-06-10 11:19
thanks :slightly_smiling_face:

ghaskins
2016-06-10 11:20
yw

simon
2016-06-10 12:54
behave tests are totally not generic at all

simon
2016-06-10 12:54
query needs security to be enabled?

simon
2016-06-10 12:55
but only one flavor of query?

simon
2016-06-10 14:45
i'm developing an new behave test and i get this error message: `Assertion Failed: Failed to POST to http://172.17.0.5:5000/devops/invoke: {"Error": "User not logged in. Use the '/registrar' endpoint to btain a security token."} `

simon
2016-06-10 14:45
why?

hgabor
2016-06-10 15:12
maybe some kind of security is enabled in core.yaml which isnt by default?

hgabor
2016-06-10 15:12
https://travis-ci.org/hyperledger/fabric/builds/135626255 I have this. It seems to be a build failure and not an error in a test case, am I right?

hgabor
2016-06-10 15:13
@simon: maybe some kind of security is enabled in core.yaml which isnt by default? just a guess

simon
2016-06-10 15:14
invoke to vp0 works, but not to vp1

simon
2016-06-10 15:14
so i think something in behave tests is wrong

hgabor
2016-06-10 15:14
could you show me that test? maybe, maybe I can help something

tuand
2016-06-10 15:14
aha ! i think you've got to log on to vp1

hgabor
2016-06-10 15:15
I mean in private

tuand
2016-06-10 15:16
try the `i register with ca supplying username and secret on peer` directive

tuand
2016-06-10 15:17
one of the guys in the lab ran into that yesterday

simon
2016-06-10 15:22
aha!

simon
2016-06-10 15:22
okay then

simon
2016-06-10 15:25
tuand: doesn't work

simon
2016-06-10 15:25
i already register on vp0

simon
2016-06-10 15:25
but i don't think i can register on vp1 as well

tuand
2016-06-10 15:26
use test_user1

jonathanlevi
2016-06-10 18:35
Can we expedite 1772, if possible?

jonathanlevi
2016-06-10 18:36
Not my issue, but we'll be happy to have the framework in for other libs.

jonathanlevi
2016-06-10 21:39
Thank you @ghaskins.

jonathanlevi
2016-06-10 21:40
--- On a separate note, unless there's any objection, we should probably change the OBCCA prefix in the `membersrvc` CA configuration/settings.

jonathanlevi
2016-06-10 21:41
After chatting with Gari, I put together an issue for calling it simply "CA_....": See https://github.com/hyperledger/fabric/issues/1797 (as there's also a hackathon coming up)

ghaskins
2016-06-10 21:41
on that note, the “CORE_” prefix seems suboptimal to me

jonathanlevi
2016-06-10 21:42
Go on please...

ghaskins
2016-06-10 21:42
even if just prefixed with HLF_ or something it would seem more appropriate to me

ghaskins
2016-06-10 21:42
HLF_CORE, HLF_CA, etc

jonathanlevi
2016-06-10 21:43
Taking a look at what we have... (for consistency)

jonathanlevi
2016-06-10 21:44
So /core/config - HYPERLEDGER

jonathanlevi
2016-06-10 21:44
And /core/chaincode - CORE

jonathanlevi
2016-06-10 21:44
and we have CORE_NOOP

jonathanlevi
2016-06-10 21:45
`peer` btw has: `core` (lowercase)

jonathanlevi
2016-06-10 21:46
I like the HLF_ prefix. What should we do with the HYPERLEDGER one though?

jonathanlevi
2016-06-10 21:48
Oh, wait. The `HYPERLEDGER` is just hardcoded for the setup test, it seems. I'm 100% happy with `HLF_CORE` and `HLF_CA`. Any other suggestions?

ghaskins
2016-06-10 21:51
that would satisfy me i think

jonathanlevi
2016-06-10 21:54
I'll update the issue...

jonathanlevi
2016-06-10 21:55
BTW: Do we want to add a label for `GoodFirstBug` or so? Similar to: https://wiki.mozilla.org/Good_first_bug

jonathanlevi
2016-06-10 21:56
I'm asking because on one hand, we already have the `help wanted` on the other hand, it's nice to highlight some of these as `beginner friendly` (which is more than just help wanted)

arnaud
2016-06-10 23:14
@jonathanlevi: we currently have a rather messy situation with our configuration set up discussed in #578 which may have bearing on this though

jonathanlevi
2016-06-10 23:16
@arnaud: fair enough. I don't mind focusing on the `membersrvc` fix for now then... because the `OBC` certainly needs to be removed (one way or another)...

arnaud
2016-06-10 23:16
true

jonathanlevi
2016-06-10 23:16
... and we'll worry about consistency later? WDYT?

arnaud
2016-06-10 23:17
that's fine, it's just that someone new may get confused about the current mess

arnaud
2016-06-10 23:17
so the labeling as Good_first_bug might trip them

jonathanlevi
2016-06-10 23:18
Point taken. I actually did specify the exact fix (steps) in 1797, trying to be super clear.

arnaud
2016-06-10 23:18
ok, good enough

jonathanlevi
2016-06-10 23:18
Focused there only on 2 or 3 files (under `membersrvc`). Yeah, didn't want to suggest a cross-component fix right away, etc.

jonathanlevi
2016-06-10 23:20
Just thinking about @ghaskins 's suggestion, to make a prefix more consistent.... but we can tackle this later on (or actually start with the `CA_`... as originally suggested)

jonathanlevi
2016-06-10 23:20
Might feel weird to have only `HLF_CA_....` and no other prefixes. I'm fine with either.

arnaud
2016-06-10 23:21
oh, I agree with the goal!

arnaud
2016-06-10 23:21
it's just that I've looked into the configuration stuff and it's a mess

jonathanlevi
2016-06-10 23:22
Oh, yeah!

jonathanlevi
2016-06-10 23:22
(you can say that one again ;-))

arnaud
2016-06-10 23:22
:slightly_smiling_face:

jonathanlevi
2016-06-10 23:24
I'll welcome newbies to our part of the world for now.... trying to keep `membersrvc` sharing the crypto, relatively self-contained, but also consistent with the rest of the project.

jonathanlevi
2016-06-10 23:24
One YAML at a time :wink: @arnaud: Have a good weekend, btw.

arnaud
2016-06-10 23:24
sounds reasonable indeed

arnaud
2016-06-10 23:24
have a good one

jonathanlevi
2016-06-11 01:38
--- Any idea what's up with the Travis build here: https://github.com/hyperledger/fabric/pull/1799

jonathanlevi
2016-06-11 01:40
Might be a permissioning issue? (Un?)fotunately, I'm about to leave for the day... (Shabbat)

mizuki
2016-06-11 03:46
has joined #fabric-dev

ramesh
2016-06-11 14:26
Issue #1803 has been created for the Travis build failures. https://github.com/hyperledger/fabric/issues/1803

ramesh
2016-06-11 14:40
I tried increasing the timeout time using `travis_wait 30 make unit-test` but there wasn't any change in the error message.

jonathanlevi
2016-06-12 03:59
Despite the 4MB limit on Travis' output, we were able to isolate the problem. It stems from some scenarios, only in the multi-threaded mode, and it does not occur on every set up.

jonathanlevi
2016-06-12 04:01
https://github.com/hyperledger/fabric/pull/1809 provides an immediate fix (with the least resistance, at this point) - so that we can all continue to work in the interim.

mrshah
2016-06-12 13:58
has joined #fabric-dev

jonathanlevi
2016-06-12 15:01
@ramesh: thank you for 1803. Can we (somehow) re-run the below Red PRs, on Travis? #1797 #1810 #1808 #1802 #1801 #1799 #1798 #1795 #1793 in case our good ol` Travis is not configured to do this automatically after recovery?

ramesh
2016-06-12 15:02
@jonathanlevi: Thanks for the Fix. I don't have permissions to run Travis builds. @ghaskins can you help you on this.

ghaskins
2016-06-12 15:03
im not sure theres anything I can do

ghaskins
2016-06-12 15:03
all the PRs that have failed will need to rebase to pick up the merge

ramesh
2016-06-12 15:10
Travis always clone hyperledger/fabric for every build and performs PR merge.. Shall we re-run one build to cross check?

ghaskins
2016-06-12 15:10
i thought I confirmed once that is not the case

ghaskins
2016-06-12 15:11
but sure, pick one

ramesh
2016-06-12 15:11
1797 from the above list..

ghaskins
2016-06-12 15:11
you got it, stand by

ramesh
2016-06-12 15:12
or Build#1019

ramesh
2016-06-12 15:12
PR#1793 is Build#999

ghaskins
2016-06-12 15:12
I did 1019

ramesh
2016-06-12 15:13
ok

ghaskins
2016-06-12 15:13
i couldnt find 1797

gengjh
2016-06-12 15:14
could you help to re run #1683 as well ? https://github.com/hyperledger/fabric/pull/1683

ghaskins
2016-06-12 15:15
done

ramesh
2016-06-12 15:16
Thanks haskin. Sorry for troubling you..

ghaskins
2016-06-12 15:18
not at all

ghaskins
2016-06-12 15:19
if your theory is right and this rebuild works, ill just spin up all current red builds

ghaskins
2016-06-12 15:19
maybe not today though, time for baseball :wink:

gengjh
2016-06-12 15:26
@ghaskins: :slightly_smiling_face: I like Turkey but they lost their first match. Anyway, today we still have German :soccer: :beers:

jonathanlevi
2016-06-12 15:28
@gengjh, @ghaskins : yes, it's clearly a busy day... however we look at it :wink:

ramesh
2016-06-12 15:29
hey.. It worked

ghaskins
2016-06-12 15:31
looks like you might be right

jonathanlevi
2016-06-12 15:32
This is really good news!

gengjh
2016-06-12 16:04

gengjh
2016-06-12 16:05
thanks guys

hgabor
2016-06-13 08:08
hi all

hgabor
2016-06-13 08:10
I have a PR with a failing build. More precisely failing behave tests: https://travis-ci.org/hyperledger/fabric/builds/136169933 How can I get more output or any hints what the error was? That behave test works on my machine.

yacovm
2016-06-13 12:54
Hi. Regarding this issue: https://github.com/hyperledger/fabric/issues/1751 Why would we want to isolate executions? shouldn't the one that implements the chaincode take care of concurrent invocations?

ghaskins
2016-06-13 13:04
@yacovm: not in my opinion

ghaskins
2016-06-13 13:05
the only persistence that a chaincode should have should be its putstate object…and we should develop frameworks that make that easy/apparent

ghaskins
2016-06-13 13:05
what @simon is pointing out in 1751 is that the current framework is structured in a way that implies/encourages additional persistence

simon
2016-06-13 13:06
indeed i am

ghaskins
2016-06-13 13:06
and, I agree with @simon

ghaskins
2016-06-13 13:10
related to this, we should also strive to make the launch method abstracted from the chaincode app

ghaskins
2016-06-13 13:11
e.g. it shouldnt matter if the chaincode is a standard linux application that has a main() and reaches out to the peer via GRPC or is launched as part of some other executor

ghaskins
2016-06-13 13:12
the way it is now will not only be difficult to encourage/enforce determinism, it will also be difficult to enforce isolation constraints

yacovm
2016-06-13 13:13
what if we have a stronger primitive on the stub, like a CAS?

ghaskins
2016-06-13 13:13
CAS?

yacovm
2016-06-13 13:13
compare and swap

ghaskins
2016-06-13 13:13
not clear on where you are going with this

ghaskins
2016-06-13 13:13
can you elaborate?

yacovm
2016-06-13 13:15
isn't the problem that chaincode that runs in parallel may step on each others toes?

yacovm
2016-06-13 13:15
I'm asking- what if it's "OK" for the invocations to run in parallel because the use case allows it?

yacovm
2016-06-13 13:15
why not transfer the responsibility to the chaincode implementer ?

simon
2016-06-13 13:18
to?

yacovm
2016-06-13 13:19
*to, yes

simon
2016-06-13 13:19
why?

yacovm
2016-06-13 13:19
because the implementer knows whether running something in parallel is OK or not

simon
2016-06-13 13:20
i don't understand the proposal

yacovm
2016-06-13 13:23
the issue is about that chaincode execution should prevent accidental sharing of global state, right? Let's say we take measures and solve it somehow. It adds some penalty/overhead to users who don't care about their chaincode sharing state because they implemented it in such a way that it handles it, or they just don't care because their chaincode might even not be dependent on the state. So isn't it more "flexible" to have the user(implementor of chaincode) worry about sharing of global state among invocations?

simon
2016-06-13 13:26
yes, more flexible, but also dangerous

muralisr
2016-06-13 13:28
@yacovm: there are many things to consider here IMO…. the assumption that implementer knows if invoke to chaincodes ( or different invoke to the same chaincode) can be run in parallel is a big one in a shared ledger env.

simon
2016-06-13 13:28
the system already runs invokes serially

simon
2016-06-13 13:29
it just can also run queries in parallel

simon
2016-06-13 13:29
chaincode *must not* share state between concurrent query/invocation, nor across invocations

simon
2016-06-13 13:30
therefore providing an API that suggests such a pattern is bad

simon
2016-06-13 13:30
and instead we should make it hard or impossible to make such a mistake

yacovm
2016-06-13 13:31
I see now. It's like, to prevent abuse?

yacovm
2016-06-13 13:32
why not delete the fields with reflection or something, instead of forking?

muralisr
2016-06-13 13:32
however, going back to the original problem - things like global var detection, invalid package use detection (time, rand… for example) shouldn’t be hard to do

muralisr
2016-06-13 13:32
either statically or dynamically

muralisr
2016-06-13 13:32
of course, there are probably smart ways of doing those that’s worth investigation

yacovm
2016-06-13 13:33
good thing go is static typing and there is no "eval" ( I think)

yacovm
2016-06-13 13:33
ok thanks for the clarification!

simon
2016-06-13 13:34
what fields?

muralisr
2016-06-13 13:34
can you elaborate on the no “eval” points please ?

simon
2016-06-13 13:34
muralisr: it's impossible to do

simon
2016-06-13 13:34
halting problem

yacovm
2016-06-13 13:34
global fields of the file

muralisr
2016-06-13 13:34
what is impossible @simon ?

muralisr
2016-06-13 13:35
I’m not claiming we’ll have 100% detection… just best effort

simon
2016-06-13 13:35
to make sure a program doesn't do X

simon
2016-06-13 13:35
we should just use a DSL that prevent anything non-deterministic

simon
2016-06-13 13:35
we don't even have to come up with it

simon
2016-06-13 13:35
they exist

muralisr
2016-06-13 13:37
again, all I’m saying is its worth doing simple things to prevent common issues. If we can do that statically only, we should do at least that

simon
2016-06-13 13:38
we need to patch go for certain things

muralisr
2016-06-13 13:38
yes

muralisr
2016-06-13 13:38
It’ll be interesting to look at what go playground does for starters

yacovm
2016-06-13 13:38
hmm good idea

yacovm
2016-06-13 13:38
what do you mean patch go?

simon
2016-06-13 13:40
playground doesn't need to be deterministic :slightly_smiling_face:

muralisr
2016-06-13 13:42
I was thinking it has lessons we can use… i think it constrains uses

yacovm
2016-06-13 13:42
@simon: but if you use a DSL then how can you still use the plain go code?

simon
2016-06-13 13:43
you don't

yacovm
2016-06-13 13:43
oh, but then it deprecates existing code

simon
2016-06-13 13:43
yes

simon
2016-06-13 13:43
well, with consensus v2 it doesn't have to be deterministic

simon
2016-06-13 13:43
it just needs to appear deterministic

lhaskins
2016-06-13 16:55
has joined #fabric-dev

hgabor
2016-06-13 19:30
hey, we have this: https://github.com/hyperledger/fabric/pull/1721 please review it, it would be good to merge

arnaud
2016-06-13 22:19
does anybody know who developed logging.go?

arnaud
2016-06-13 22:20
there seems to be an inconsistency between what's referred to as "default"

bcbrock
2016-06-13 22:21
It was me

arnaud
2016-06-13 22:21
hi!

arnaud
2016-06-13 22:21
maybe you can help me understand how it's supposed to be used

kostas
2016-06-13 22:21

bcbrock
2016-06-13 22:22
It allows different defaults to be applied to different subcomamds of teh peer

arnaud
2016-06-13 22:22
@kostas: oh, I know, that's what I'm looking into actually

arnaud
2016-06-13 22:22
yes, I understand that

arnaud
2016-06-13 22:23
I think one difficulty comes from the "default" logging_level

arnaud
2016-06-13 22:23
everything else that is made of several words relates to nesting in yaml

arnaud
2016-06-13 22:24
but not that one

bcbrock
2016-06-13 22:24
I’m note sure what you mean by “several words"

arnaud
2016-06-13 22:25
then it is unclear to me whether setting it is really just a default - as in: used if there isn't a more specific setting - or as an override

arnaud
2016-06-13 22:25
sorry, multiwords like peer.tls.cert.file

bcbrock
2016-06-13 22:25
What are you tryiong top do?

arnaud
2016-06-13 22:25
debug :slightly_smiling_face:

bcbrock
2016-06-13 22:26
And what do you want to happen>

arnaud
2016-06-13 22:26
but to be fair maybe I'm just not understanding how it's supposed to work!

bcbrock
2016-06-13 22:26
Then I haven’t documented it well enough :slightly_smiling_face:

bcbrock
2016-06-13 22:27
Are you trying to set a particular module to DEBUG and anther one to another level?

arnaud
2016-06-13 22:27
so tell me this: what has precedence if both logging_level and logging.peer are set?

bcbrock
2016-06-13 22:28
The environment variables are always supposed to take precedence

bcbrock
2016-06-13 22:29
command line flag takes precendence over YAML file

kostas
2016-06-13 22:29
> make: Warning: File `Makefile' has modification time 4.4e+02 s in the future is this a normal message to get when invoking `make all`? I'm on `bab9e4` (@ghaskins is probably my best bet for this)

arnaud
2016-06-13 22:30
well, that doesn't seem to happen

arnaud
2016-06-13 22:30
and there seem to be several reasons for that

arnaud
2016-06-13 22:31
I believe the order of precedence is meant to be command line options, env var, yaml file

arnaud
2016-06-13 22:31
but then you have another axis with the logging-level vs command levels

arnaud
2016-06-13 22:32
and not all modules seem to check the latter

arnaud
2016-06-13 22:32
crypto for one doesn't

bcbrock
2016-06-13 22:33
Crypto was not implemented correctly:

arnaud
2016-06-13 22:33
setting CORE_LOGGING_LEVEL has no effect on crypto logging level


bcbrock
2016-06-13 22:34
Or shoudl I say, was not implemented in keeping with the other parts of this system

bcbrock
2016-06-13 22:34
This issue was opened after redoing logging.go

arnaud
2016-06-13 22:34
thanks for the pointer

arnaud
2016-06-13 22:35
the combination of the various related bugs makes it a bit hard to figure out 1) what's going on, 2) what should be going on! :slightly_smiling_face:

arnaud
2016-06-13 22:36
so, let's talk a bit about logging-level if you don't mind

bcbrock
2016-06-13 22:36
Sure

arnaud
2016-06-13 22:36
did you get what I meant about the nesting?

bcbrock
2016-06-13 22:37
Not really

arnaud
2016-06-13 22:37
in all other cases when there is a variable CORE_FOO_BAR it maps to foo.bar in the yaml file

arnaud
2016-06-13 22:37
these are nested properties

bcbrock
2016-06-13 22:37
I get what you mean

arnaud
2016-06-13 22:38
but logging-level doesn't, right?

bcbrock
2016-06-13 22:38
Right

arnaud
2016-06-13 22:38
or logging_level rather - which is another point of confusion

arnaud
2016-06-13 22:39
there is a bug in peer/main.go which maps the wrong keys and when I tried to fix it I broke that one because I didn't realize it wasn't a nested property

arnaud
2016-06-13 22:39
I now understand but it makes me wonder whether this should be rename to avoid any such confusion

bcbrock
2016-06-13 22:42
I was reacting to the fact that the “peer” has many subcommands, yet each should have a different default logging level. But it seemed redundant to have to say -peer-logging-level=foo when you were executing the peer command.

bcbrock
2016-06-13 22:42
Why do we make a server application also functino as a client?

arnaud
2016-06-13 22:42
well, let's not derail :wink:

bcbrock
2016-06-13 22:43
BUt that derailment is tied up in the issue you are raiosing

arnaud
2016-06-13 22:43
I see what you mean but from a logging setting point of view I don't think that's relevant

bcbrock
2016-06-13 22:43
A server should log at the INFO level by default

arnaud
2016-06-13 22:44
the commands could be completely different and we'd have the problem

bcbrock
2016-06-13 22:44
A client at WARNING probably

arnaud
2016-06-13 22:44
ah, I see what you mean

arnaud
2016-06-13 22:45
tell me something else, in logging.go, what you call "defaultLevel" isn't actually the default, is it?

arnaud
2016-06-13 22:45
on the first line it is, but not after that

arnaud
2016-06-13 22:45
sorry, I mean LoggingInit

bcbrock
2016-06-13 22:46
Why do you think it is not the default?

arnaud
2016-06-13 22:47
whats going to override that?

bcbrock
2016-06-13 22:48
Any env. var, flag or Yaml entry that specifies a default

bcbrock
2016-06-13 22:48
a different default

arnaud
2016-06-13 22:48
you mean a different *level* :slightly_smiling_face:

bcbrock
2016-06-13 22:48
Yes a different default level

arnaud
2016-06-13 22:48
but, wait, why "default"??

arnaud
2016-06-13 22:48
at some point it's no longer a default, right?

arnaud
2016-06-13 22:49
default, is only a backup type of setting

arnaud
2016-06-13 22:49
if you have nothing else you take that

bcbrock
2016-06-13 22:49
Why is that word not appropriate? (Default)

bcbrock
2016-06-13 22:50
If you delete all of the YAML entries you get the default

arnaud
2016-06-13 22:50
because it's as if you never have an actual setting you only have defaults

arnaud
2016-06-13 22:50
no, the yaml has lower precedence you said

bcbrock
2016-06-13 22:51
If you delete yaml, and dont give a command-line flag and dont have an env. var this is what you get

bcbrock
2016-06-13 22:51
somebody has to specify the default

arnaud
2016-06-13 22:51
ah! I understand

arnaud
2016-06-13 22:51
that's the default in the code, right?

bcbrock
2016-06-13 22:51
I think op/go-logging defaults to ERROR

bcbrock
2016-06-13 22:51
Yes, this default is only used if no other soec. is given

bcbrock
2016-06-13 22:52
spec

arnaud
2016-06-13 22:52
I get it, thanks

arnaud
2016-06-13 22:57
so, I looked into https://github.com/hyperledger/fabric/issues/578 and I agree with what @kostas said there

arnaud
2016-06-13 22:57
the mapping is wrong and the fix is simple in peer/main.go

kostas
2016-06-13 22:59
@arnaud: cool, I'll put in a PR soon (although I'll want to see how files other `main.go` are affected by this)

arnaud
2016-06-13 23:00
yeah. that's what I was doing which is how I got into this discussion :wink:

arnaud
2016-06-13 23:00
did you try your fix on peer/main.go?

arnaud
2016-06-13 23:00
because the one mapping/bind you must not change is logging_level/logging-level

arnaud
2016-06-13 23:01
or you'd have to change the value fetched from logging.go

arnaud
2016-06-13 23:01
LoggingInit has: spec := viper.GetString("logging_level")

arnaud
2016-06-13 23:02
that's where I find the name a bit tricky

arnaud
2016-06-13 23:03
the characters _ - . have a meaning except in this case

kostas
2016-06-13 23:03
@arnaud: do you want us to go on with this conversation on the #578 issue page? I don't want this feedback to be lost

arnaud
2016-06-13 23:03
sure I can add something there

kostas
2016-06-13 23:03
thank you!

arnaud
2016-06-13 23:04
I primarily came here to try and get some info to better understand

arnaud
2016-06-13 23:04
thanks

arnaud
2016-06-13 23:04
thanks @bcbrock for your patience with me :slightly_smiling_face:

bcbrock
2016-06-13 23:06
Ok, let me know if I can help further

arnaud
2016-06-13 23:09
ah, here is another tricky part: so logging-level is the default, but it also is used to override everything with the env variable CORE_LOGGING_LEVEL?

arnaud
2016-06-13 23:09
the peer command has this: mainFlags.String("logging-level", "", "Default logging level and overrides, see core.yaml for full syntax")

arnaud
2016-06-13 23:10
how can it be both the default and the override?

bcbrock
2016-06-13 23:10
The specification string includes both a default spec. and overrides

bcbrock
2016-06-13 23:10
info:chaincode=debug

arnaud
2016-06-13 23:10
I see

bcbrock
2016-06-13 23:10
only debugs chaincode

arnaud
2016-06-13 23:11
so, it's a setting that defines the default for all commands plus overrides for specific commands

bcbrock
2016-06-13 23:11
Yes

bcbrock
2016-06-13 23:12
No not commands, logging “modules"

arnaud
2016-06-13 23:12
ah, right!

arnaud
2016-06-13 23:13
problem is the yaml file talks about commands and subcommands

arnaud
2016-06-13 23:13
and some settings do map to commands

arnaud
2016-06-13 23:14
but I understand there isn't a 1-1 mapping between commands and modules

bcbrock
2016-06-13 23:14
Maybe it needs more explanation of what a module is

bcbrock
2016-06-13 23:15
Yes, I think it does, a normal user won’t know what these are

bcbrock
2016-06-13 23:15
referring to

bcbrock
2016-06-13 23:16
This is really an expert setting

bcbrock
2016-06-13 23:16
for developers

grapebaba
2016-06-14 04:45
has joined #fabric-dev

cca
2016-06-14 09:57
has joined #fabric-dev

zuowang
2016-06-14 11:50
has joined #fabric-dev

ezhil
2016-06-14 13:55
has joined #fabric-dev

elisabetta
2016-06-14 15:01
has joined #fabric-dev

elisabetta
2016-06-14 15:03
hi, I noticed that peer and member services binaries have been recently moved in the build, they're no longer under fabric/<dir> but in fabric/build/bin

elisabetta
2016-06-14 15:04
from there, they don't seem to start fine, however, if I copy them into the original directory they do..

elisabetta
2016-06-14 15:04
can anyone help? any advice on how to start them would be really appreciated

ghaskins
2016-06-14 15:05
Can you paste the error you are seeing?

ghaskins
2016-06-14 15:05
They start fine for me

elisabetta
2016-06-14 15:05
panic: Fatal error when reading core config file: Unsupported Config Type ""goroutine 1 [running]: panic(0x2aa1819d100, 0xc82019bf60) /opt/hyperledger/go/src/runtime/panic.go:464 +0x400 main.main() /opt/hyperledger/git/src/github.com/hyperledger/fabric/peer/main.go:268 +0x86a 2:53 does anyone have an idea of what that means?

elisabetta
2016-06-14 15:06
I'm running out of containers

arnaud
2016-06-14 15:18
what's your GOPATH set to?

elisabetta
2016-06-14 15:24
CORE_PEER_ID=vp1 CORE_PEER_ADDRESSAUTODETECT=true CORE_LOGGING_PEER=DEBUG GOPATH=/opt/hyperledger ./peer node start

elisabetta
2016-06-14 15:25
and peer is under /opt/hyperledger/git/src/github.com/hyperledger/fabric/build/bin

elisabetta
2016-06-14 15:26
maybe the GOPATH is not right and it used to work because everything was under the same directory

elisabetta
2016-06-14 15:26
what should GOPATH be set to?

ezhil
2016-06-14 15:32
in your case it can be set to: /opt/hyperledger/git/

ezhil
2016-06-14 15:33
export GOPATH=/opt/hyperledger/git/

elisabetta
2016-06-14 15:34
brilliant, thanks. It works!

nits7sid
2016-06-14 16:44
DeleteTable(tablename) does not works. Gives this error on chaoncode terminal console. 21:57:47.240 [shim] DEBU : [mycc]Sending RANGE_QUERY_STATE 2016/06/14 21:57:47 transport: http2Client.notifyError got notified that the client transport was broken EOF. 21:57:47.392 [shim] ERRO : Received error from server: rpc error: code = 13 desc = "transport is closing", ending chaincode stream

simon
2016-06-14 16:45
BOOM

simon
2016-06-14 16:45
any logs for the peer?

nits7sid
2016-06-14 16:46
panic: runtime error: invalid memory address or nil pointer dereference panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0x62c861]

simon
2016-06-14 16:46
more?

nits7sid
2016-06-14 16:46
goroutine 30 [running]: panic(0xd5afc0, 0xc820010100) /opt/go/src/runtime/panic.go:464 +0x3e6 http://github.com/hyperledger/fabric/core/chaincode.(*Handler).handleRangeQueryState.func1.1(0xc820284080, 0xc82012b8b0, 0xc820043d80) /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:651 +0x261 panic(0xd5afc0, 0xc820010100) /opt/go/src/runtime/panic.go:426 +0x4e9 http://github.com/hyperledger/fabric/core/chaincode.(*Handler).handleRangeQueryState.func1(0xc820284080, 0xc82012b8b0) /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:700 +0xbef created by http://github.com/hyperledger/fabric/core/chaincode.(*Handler).handleRangeQueryState /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:736 +0x3f hyperledger@hj-ctocto2126:/opt/gopath/src/github.com/hyperledger/fabric/peer$

simon
2016-06-14 16:47
that's good information

simon
2016-06-14 16:47
please open an issue

simon
2016-06-14 16:47
with this trace attached

nits7sid
2016-06-14 16:47
yeah okay!

arnaud
2016-06-14 18:12
@bcbrock: hi, is there any reason only a few settings are settable via command line options?

bcbrock
2016-06-14 18:12
It was like that when I joined the project

arnaud
2016-06-14 18:13
it seems rather arbitrary right now

bcbrock
2016-06-14 18:13
I think I remember Binh saying once that it was hard to pass env. vars. in Windows, so they added a few cmd. line vars.

bcbrock
2016-06-14 18:13
My vote would be to remove them all

bcbrock
2016-06-14 18:14
Or maybe someone could write a code generator from the YAML file

arnaud
2016-06-14 18:15
for what it's worth setting variables on Windows is no problem when you use cygwin :wink:

bcbrock
2016-06-14 18:15
That’s cause you cheat!

arnaud
2016-06-14 18:15
only way to survive you mean!

bcbrock
2016-06-14 18:15
Yes

arnaud
2016-06-14 18:15
I could never have gotten used to working on a Windows box without it

arnaud
2016-06-14 18:16
but who runs any of this on Windows directly?

arnaud
2016-06-14 18:16
aren't most people running it on a virtualbox on WindowS?

arnaud
2016-06-14 18:16
that argument sounds very weak

bcbrock
2016-06-14 18:17
Good question

arnaud
2016-06-14 18:17
maybe @binh can shed some light?

arnaud
2016-06-14 18:17
@binhn

arnaud
2016-06-14 18:45
I rather like command line options but unless we do it right I would agree that we're probably better off not having any

arnaud
2016-06-14 18:46
for one thing I would expect security-enabled and privacy-enabled to be supported

sheehan
2016-06-14 19:18
@kostas: regarding the future time warning when running `make`, I see the same problem. I believe the problem is that my vagrant clock is behind my host clock

ghaskins
2016-06-14 19:31
i just started seeing that too, i feel like its new

ghaskins
2016-06-14 19:32
not sure if its only because now I am aware of it, but I dont recall seeing it before

binhn
2016-06-14 19:40
@arnaud: i haven’t followed yours and bishop’s discussion, but re env vars on Windows (and I am not a Windows guy either) the option seems to involve multiple commands like ``` set v1=s1 set v2=s2 peer node start ```

sheehan
2016-06-14 19:40
@ghaskins: based on the history in my console, it only started recently. I never compared the clocks before

arnaud
2016-06-14 19:42
@binhn: the question was really about the command line options/flags a la --peer-tls-enabled

arnaud
2016-06-14 19:43
there is currently code in peer/main.go to support some such options but it doesn't work

arnaud
2016-06-14 19:43
it's easy to fix but it led me to wonder why we only support a few such options and not others

arnaud
2016-06-14 19:44
for instance I can't say --security-enabled

arnaud
2016-06-14 19:45
it would seem that if we wanted to add flags we should do it more thoroughly rather just for a few settings

binhn
2016-06-14 19:45
ah right, early on, we wanted to make that easy for some guy on windows, but now the number of config options has increased many folds

binhn
2016-06-14 19:46
i would agree to remove them

arnaud
2016-06-14 19:46
that's what bishop was advocating for

arnaud
2016-06-14 19:47
I will send an email to the list to ask if anyone has a problem with that

arnaud
2016-06-14 19:47
presumably it won't bother anyone because it doesn't work right now anyway! :slightly_smiling_face:

binhn
2016-06-14 19:48
ok - good idea; i think a nice thing at the beginning has been out grown

arnaud
2016-06-14 19:49
ok, that explains why only a few settings are supported

arnaud
2016-06-14 19:49
thanks

arnaud
2016-06-14 20:16
one more piece to this puzzle: we currently have one setting which can only be set via command flag: --peer-chaincodedev

bcbrock
2016-06-14 20:23
I can’t think of a reason to make that one special, "FOO =bar peer” is just as much to type as “peer —foo=bar"

arnaud
2016-06-14 20:43
I'm all for homogeneity I don't see why this one is singled out either

arnaud
2016-06-14 20:49
CORE_PEER_CHAINCODEDEV=true peer node start doesn't work

kostas
2016-06-15 00:06
@sheehan: thanks, any easy fixes?

jonathanlevi
2016-06-15 01:22
@sheehan: Do we need to manually rebase 1810? [ @grapebaba ]

jonathanlevi
2016-06-15 01:23
+ mind casting another review on PR 1781, please?

grapebaba
2016-06-15 01:45
@jonathanlevi: rebased

grapebaba
2016-06-15 02:21
after update i got a error in behave test in my local master, need do environment clean?

grapebaba
2016-06-15 02:37
oh strange, disappeared

hgabor
2016-06-15 12:19
I am trying to make protos but

hgabor
2016-06-15 12:19
I get this error

hgabor
2016-06-15 12:19
+ protoc --go_out=plugins=grpc:/opt/gopath/src /usr/include/google/protobuf/timestamp.proto /usr/include/google/protobuf/timestamp.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think). make: *** [protos] Error 1

hgabor
2016-06-15 12:29
I will try to recreate the vagrant VM

sheehan
2016-06-15 12:44
@jonathanlevi: the comment I made in 1810 has not been resolved

grapebaba
2016-06-15 12:58
@sheehan: i have not seen your comment in 1810

sheehan
2016-06-15 12:59
@grapebaba: sorry, got the number mixed up. Meant to say 1781

hgabor
2016-06-15 13:00
after recreating the VM, I m still unable to build the protos

sheehan
2016-06-15 13:01
@hgabor: this in in vagrant or outside? I just tried inside and it worked

hgabor
2016-06-15 13:01
inside

hgabor
2016-06-15 13:01
1st problem is that protoc-gen-go is not installed

grapebaba
2016-06-15 13:02
:relaxed:

hgabor
2016-06-15 13:03
@sheehan: I tried make gootool.protoc-go-gen but it gives me errors

sheehan
2016-06-15 13:04
I think that’s installed in the base image. hmmmm. When was the last time you did a `vagrant destroy` `vagrant up`?

hgabor
2016-06-15 13:05
5 minutes ago

sheehan
2016-06-15 13:07
ha, ok. should be good

hgabor
2016-06-15 13:08
now I managed to run make gotool.protoc-gen-go after some sudo mkdir and chmod

hgabor
2016-06-15 13:09
but I get this:

hgabor
2016-06-15 13:09
vagrant@ubuntu-1404:/opt/gopath/src/github.com/hyperledger/fabric$ make protos ./devenv/compile_protos.sh + protoc --go_out=plugins=grpc:/opt/gopath/src /usr/include/google/protobuf/timestamp.proto google/protobuf/timestamp.pb.go: while trying to create directory /opt/gopath/src/google: Permission denied

hgabor
2016-06-15 13:09
this is some permission problem in the VM


sheehan
2016-06-15 13:12
do the permissions on your $GOPATH look different?

hgabor
2016-06-15 13:12
vagrant@ubuntu-1404:/opt/gopath/src/github.com/hyperledger/fabric$ ls -l $GOPATH total 12 drwxrwxrwx 2 root root 4096 Jun 15 13:07 bin drwxr-xr-x 3 root root 4096 Jun 15 12:55 pkg drwxr-xr-x 3 root root 4096 Jun 15 12:42 src

hgabor
2016-06-15 13:13
root is the owner


sheehan
2016-06-15 13:13
seems like that line never ran for some reason

hgabor
2016-06-15 13:13
isn't that run automatically?

hgabor
2016-06-15 13:14
I just called vagrant destroy... vagrant up, vagrant ssh

sheehan
2016-06-15 13:14
yeah, wondering if there’s an error during `vagrant up`

hgabor
2016-06-15 13:14
I did it manually and now I am able to call make protos

sheehan
2016-06-15 13:15
I can try destroy/up on my system, but I did it recently and it seems to be working.

hgabor
2016-06-15 13:15
ooo my fault then... because there were errors at the compilation of peer. but I knew that I made some erroneous changes and this was not surprising for me. I thought it is just the last step that failed

hgabor
2016-06-15 13:41

ghaskins
2016-06-15 13:44

ghaskins
2016-06-15 13:45
note the workaround (run “make gotools” prior to make protos)

ghaskins
2016-06-15 13:45
its a trivial fix, so ill get this in asap

hgabor
2016-06-15 13:46
is this related to pdbft sieve fault? 8o or you mean my previous problem?

ghaskins
2016-06-15 13:47
sorry, related to protobuf compilation (im a little behind in reading slack)

kostas
2016-06-15 14:35
do we have a channel that can keep us posted on new Github issues or PRs, like we used to in the previous Slack?

ghaskins
2016-06-15 14:38
@kostas: you probably already know this, but FYI you can subscribe to the github project and then you will get emails at least

ghaskins
2016-06-15 14:38
thats what I have been doing

kostas
2016-06-15 14:39
I'm a millennial, I don't do emails! (:grin:)

kostas
2016-06-15 14:39
(sigh, I wish I was millennial) -will do Greg, thanks

jonathanlevi
2016-06-15 14:47
@kostas: I wish I was a millennial too, FWIW!

hgabor
2016-06-15 14:56
does anybody have an idea why pbft sieve test fails? https://github.com/hyperledger/fabric/pull/1719

hgabor
2016-06-15 14:56
it is frustrating as I made no changes to that

hgabor
2016-06-15 15:58
https://github.com/hyperledger/fabric/pull/1754 the same occurs for this commit, error in sieve test

hgabor
2016-06-15 15:58
pls somebody have a look :S

sheehan
2016-06-15 16:00
@jyellick: @simon ^^^

simon
2016-06-15 16:01
hi

simon
2016-06-15 16:01
what's the problem?

sheehan
2016-06-15 16:03
pbft sieve test failing for https://github.com/hyperledger/fabric/pull/1719. Is that test stable?

simon
2016-06-15 16:04
i can't even see the problem

simon
2016-06-15 16:04
do i look at travis or jenkins?

hgabor
2016-06-15 16:06
I think it was in travis raw log

hgabor
2016-06-15 16:14
@simon: if you have some time and can look at the problem and maybe find something, please write me pls, thx :slightly_smiling_face: I will be afk for some time

simon
2016-06-15 16:23
ok, jenkins must have failed for some other reason

simon
2016-06-15 16:24
travis shows it is still running

simon
2016-06-15 16:24
generally most tests are unreliable

ghaskins
2016-06-15 16:25
@simon: I had restarted @hgabor’s PRs per his request, sorry

simon
2016-06-15 16:25
ah ok

ghaskins
2016-06-15 16:25
i suspect its just an unreliable result, but we’ll see if it consistently fails

simon
2016-06-15 16:34
so, i tried to determine the cause of our poor performance

simon
2016-06-15 16:34
and i think i found it

simon
2016-06-15 16:34
goroutine scheduling latency

arnaud
2016-06-15 16:35
that doesn't sound good

simon
2016-06-15 16:40
:slightly_smiling_face:

simon
2016-06-15 16:40
we should think about restructuring this project into microservices

simon
2016-06-15 16:41
if we had one ledgerservice which does all the database ops

simon
2016-06-15 16:41
that would improve performance

simon
2016-06-15 16:42
also maybe then think about a different primitive than tcp sockets

arnaud
2016-06-15 16:42
that's quite an undertaking you're talking about

ghaskins
2016-06-15 16:43
if the microservices would be intended to run on the same box, there are a ton of options that are far better than tcp

ghaskins
2016-06-15 16:44
i assume the goal is to break up the scheduling domains of the go routines

simon
2016-06-15 16:49
yes

muralisr
2016-06-15 16:52
(apologize for introducing a digression…. ) travis build is failing for PR https://github.com/hyperledger/fabric/pull/1826… the failure is while running core/ledger tests I believe (the log is long and got cut)

muralisr
2016-06-15 16:52
any ideas ?

cbf
2016-06-15 20:23
what @simon said at 12:40 et +100000000000000000

cbf
2016-06-15 20:24
no seriously, who writes monolith anymore... that said best to decompose a monolith than to start with microservices

cbf
2016-06-15 20:25
as to @ghaskins point on IPC depends on whether we do want all in one process or separate independently managed containers

muralisr
2016-06-15 20:38
@simon microservices introduce separation of concerns and looser coupling between components. Typically they increase latency overall and not decrease it…. but maybe I’m missing something. Also curious about gorouting scheduler latency ? how do you figure that ?

muralisr
2016-06-15 20:39
having said that, looser coupling between components and not using tcp as a mechanism for IPC, definitely +1


muralisr
2016-06-15 20:42
thanks, @tuand. will read

yacovm
2016-06-16 09:24
In the peer: we have the chaincode_support.go that sends a transaction to chaincode/handler.go, and the chaincode/handler.go sends transactions to the chaincode and receives replies from it, and notifies the chaincode_support.go's goroutine that invoked Execute. Why is that? why doesn't the chaincode_support.go send the transaction itself to the chaincode? after all- doesn't it effect throughput with all these goroutine channel handshakes?

simon
2016-06-16 09:35
no

simon
2016-06-16 09:36
goroutines are very fast in communicating via channels

yacovm
2016-06-16 09:36
so it's built this way just because of "design patterns"?

simon
2016-06-16 09:36
i have no idea

simon
2016-06-16 09:37
i wondered the same

simon
2016-06-16 09:37
something about the FSM maybe?

yacovm
2016-06-16 09:47
No idea, I was asking just because of [1], if you search for "2252 ns/op" some guy claims there that using channels isn't so fast as just using simply mutexes . I'm asking why isn't the threading model using the same Executor goroutine to send the message to the chaincode, and instead (what it does now) is: send a message to some goroutine, wait for the goroutine to send the message back to us. Was just wondering, that's all... [1] http://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/

simon
2016-06-16 09:47
yea it is not as fast

simon
2016-06-16 09:48
i don't know why

simon
2016-06-16 09:48
all i know is that we need to switch to a microservice multiple process architecture

simon
2016-06-16 09:48
if we want to improve performance

yacovm
2016-06-16 09:52
You mean, separating between consenters, and committers and the new architecture doc?

simon
2016-06-16 09:52
no

simon
2016-06-16 09:53
i mean separating between REST frontend service, consensus service, ledger + chaincode service

yacovm
2016-06-16 09:54
ok

simon
2016-06-16 09:55
the reason for that is that our performance right now is limited by the latency between chaincode and chaincode handler

simon
2016-06-16 09:55
of course there is some inherent context switch and tcp latency

simon
2016-06-16 09:55
but the bigger issue is the goroutine scheduler

simon
2016-06-16 09:56
if there are many runnable goroutines, the single chaincode handler goroutine waiting for the next message from the chaincode is very unlikely to be scheduled

simon
2016-06-16 09:56
which increases latency significantly

yacovm
2016-06-16 09:57
oh, there is a single one? not a handler per chaincode?

simon
2016-06-16 09:57
well it doesn't matter

simon
2016-06-16 09:57
you can only invoke one chaincode at a time

zuowang
2016-06-16 10:35
build/bin/peer network login jim -p 6avZQLwcUe9b

zuowang
2016-06-16 10:35
how to logout jim?

zuowang
2016-06-16 10:36
:grin:

simon
2016-06-16 10:37
not, i think

cbf
2016-06-16 11:56
kiil -9?

yacovm
2016-06-16 11:56
Anyone here familiar with the code of the ledger bucket tree ?

sheehan
2016-06-16 12:32
@simon: have you investigated LockOSThread https://golang.org/pkg/runtime/#LockOSThread as a possible way to give priority to the chaincode handler goroutine?

sheehan
2016-06-16 12:33
@yacovm: for the ledger bucket tree, @manish-sethi is the expert

yacovm
2016-06-16 12:48
@sheehan: thanks! I opened an issue (1865) of a peer crash because of state transfer and I'd also like to patch it, but I'm not familiar with the code (and it's not really documented).

sheehan
2016-06-16 12:54
@yacovm: There’s high level documentation at https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md in section 3.2.2.1.1 if you haven’t seen it already

manish-sethi
2016-06-16 12:56
@yacovm: I just looked at issue 1865.

manish-sethi
2016-06-16 12:56
did you change the bucket tree configurations in core.yaml after inserting a few transactions?

yacovm
2016-06-16 12:56
I didn't touch it, why?

yacovm
2016-06-16 12:57
all nodes are spawned from the same yaml file, which is the core.yaml that you get when cloning the latest build

manish-sethi
2016-06-16 12:58
OK, changing configuration could have been one of the potential cause of this error. SO, just wanted to rule that out

yacovm
2016-06-16 12:58
sure

yacovm
2016-06-16 13:04
By the way- why does the system behave this way: I run 5000 transactions and get HTTP 200 for all of them, but after that, the chain size is still increasing (verifying with GET). Isn't it supposed to by synchronous and serial (meaning- the REST handler returns 200 only when the block has been written to the FS) ?

manish-sethi
2016-06-16 13:14
No, its asynch. HTTP 200 is only for the acceptance of your transaction.

yacovm
2016-06-16 13:17
But the REST handler returns *after* the consensus handler accepted that transaction, right?

simon
2016-06-16 13:40
@sheehan: i have not. will do right now

simon
2016-06-16 14:00
@sheehan: doesn't seem to help

simon
2016-06-16 14:00
oddly enough

sheehan
2016-06-16 14:00
:-1:

simon
2016-06-16 14:00
:confused:

sheehan
2016-06-16 14:05
In Java the thread priority stuff never seemed to work that well. The only real solution was to create a separate process and set the OS process priority. Don’t have as much experience with Go so can’t say

simon
2016-06-16 14:07
:slightly_smiling_face:


simon
2016-06-16 14:08
if you want you can give it a spin

harshal
2016-06-16 16:23
@harshal has left the channel

arnaud
2016-06-16 16:50
@ghaskins: hi Greg, in your demo earlier I saw that when you deployed with the peer command you had a log message about the chaincode being deployed successfully, did I get that right?

ghaskins
2016-06-16 16:53
@arnaud: yes, but note that magic was done for me :wink:

arnaud
2016-06-16 16:54
ah!

arnaud
2016-06-16 16:54
how did you get that??

arnaud
2016-06-16 16:54

arnaud
2016-06-16 16:55
and from what I can tell you only get that message if you use the REST api

arnaud
2016-06-16 16:55
and I haven't seen it independently of the logging level

ghaskins
2016-06-16 17:02
@arnaud: in that particular demo, I was using the rest api

ghaskins
2016-06-16 17:03
under the hood, via a node/cljs app

arnaud
2016-06-16 17:03
oh!... sneaky :wink:

arnaud
2016-06-16 17:03
ok, that explains, I just wanted to make sure I wasn't missing anything

arnaud
2016-06-16 17:04
the rest_api.go module does a lot more logging that the peer command



arnaud
2016-06-16 17:04
yes, but somehow I thought you typed something like: ./peer chaincode deploy -n mycc -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'

ghaskins
2016-06-16 17:05
sort of, it was just to that client :wink:

arnaud
2016-06-16 17:05
ok, I just missed that

arnaud
2016-06-16 17:05
thakns

ghaskins
2016-06-16 17:05

arnaud
2016-06-16 17:06
I see

arnaud
2016-06-16 17:06
it's similar enough that it fooled me :slightly_smiling_face:

ghaskins
2016-06-16 17:06
yeah, sorry, heh

arnaud
2016-06-16 17:06
nah, it's ok

ghaskins
2016-06-16 17:06
my intent was familiarity for comfort with existing example02, not confusion

ghaskins
2016-06-16 17:06
so I failed

ghaskins
2016-06-16 17:09
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F1HJMN9QQ/-.sh and commented: Heres the entire command history from the live demo

arnaud
2016-06-16 17:20
no worries, I don't blame you

arnaud
2016-06-16 17:21
it doesn't help that we have that freaking long shell prompt

ghaskins
2016-06-16 17:22
heh, thats partially my fault

ghaskins
2016-06-16 17:22
I did “export PS1=‘$ ‘“ for the demo just for that reason

ghaskins
2016-06-16 17:22
otherwise, I was typing the commands over on the right, heh

arnaud
2016-06-16 17:36
@ghaskins one more question: when I do make peer it does a whole bunch of things - like creating docker images and whatnot - which I don't need when all I do is making a small change in the go code to try out (like adding a print for tracing!) - is there a make target I can use to just rebuild the go? something more like what I would get when doing go build the old way?

ghaskins
2016-06-16 18:29
@arnaud: I know it looks superfluous, but what you are seeing is twofold: 1) the system now does a fairly precise job of detecting what artifacts had their files change, and 2) we front-load the chaincode environments into the build rather than at runtime

ghaskins
2016-06-16 18:30
that said, I had to then turn off part of the front loading in (2) because some of the platform/golang wasnt ready for it

ghaskins
2016-06-16 18:30
so, an argument could be made to turn that off until its ready (though platform/car does use it), but eventually I think thats closer to the model we need

ghaskins
2016-06-16 18:31
are you finding it really slow to build? for me it was only a few seconds more

arnaud
2016-06-16 20:20
@ghaskins: sorry, I had to work on something else for a while. I don't know how much more time this takes but it is definitely taking some significant amount of time.

ghaskins
2016-06-16 20:21
@arnaud: ok, some will be unavoidable but it can probably be improved upon from where it is now

arnaud
2016-06-16 20:21
I'm investigating the code, trying different things and every time I change one line in a go file it rebuilds all the docker stuff

ghaskins
2016-06-16 20:22
its tough to balance between “always do the right thing” and “let expert user decide whats right"

arnaud
2016-06-16 20:22
I understand

ghaskins
2016-06-16 20:22
yes, that was the intent as the system needs the src in the docker container to run, so if you change the src, it will rebuild the docker

arnaud
2016-06-16 20:22
but if we could have some intermediary target that we could use and not advertize to the average user that would be nice

ghaskins
2016-06-16 20:23
yeah, we should be able to come up with something

arnaud
2016-06-16 20:23
that's what I wanted to hear! :wink:

ghaskins
2016-06-16 20:26
longer term, i think it will be alleviated because we wont need the fabric.git src to build the chaincodes

ghaskins
2016-06-16 20:26
but in the interim, we can find some kind of workaround so thats not as annoying

arnaud
2016-06-16 20:26
yes

ghaskins
2016-06-16 20:28
@sheehan: @binhn please give consideration to #1834….it probably should be expedited IMO

sheehan
2016-06-16 20:29
will take a look now

sheehan
2016-06-16 20:31
done. was quick as I already reviewed a couple before. was just waiting for go-ahead from Ry

arnaud
2016-06-16 20:48
well, if you have a moment you could look at https://github.com/hyperledger/fabric/issues/763 :slightly_smiling_face:

cbf
2016-06-16 23:02
@arnaud can't you use go-watch https://www.npmjs.com/package/go-watch

arnaud
2016-06-16 23:05
I'm not sure that addresses my problem

arnaud
2016-06-16 23:05
from what I understand this just triggers make automatically

arnaud
2016-06-16 23:05
it doesn't make make faster

ranga
2016-06-17 00:26
is support for writing chaincode in JS available now or can chaincode only be written in golang ?

muralisr
2016-06-17 00:42
@ranga only in golang for now although work in progress for Java chaincode

muralisr
2016-06-17 00:46
@cbf @binhn @ghaskins @sheehan recent PR Travis failures due to port collision …. I believe is due to ephemeral port choice (such as 41414). I’m going to push a PR to move listening ports of my testcases to less than 30000. The change will affect only the test cases and should be safe.

ghaskins
2016-06-17 00:46
Roger, will look for it

muralisr
2016-06-17 00:46
can I have your OK please ?

muralisr
2016-06-17 00:46
great. thanks @ghaskins

muralisr
2016-06-17 00:47
I should have thought of this before… my apologies

cbf
2016-06-17 00:52
@arnaud: you could have it just go build rather than make

ghaskins
2016-06-17 00:53
@cbf this is a good point. Go build even takes advantage of pkg caching if it already exists

arnaud
2016-06-17 01:03
Well that's what I do :)

arnaud
2016-06-17 01:04
But I wanted to play along and use make!

muralisr
2016-06-17 01:30

muralisr
2016-06-17 01:30
thanks!

ghaskins
2016-06-17 01:32
seems reasonable…will wait for CI pass to complete

muralisr
2016-06-17 01:32
sure

jonathanlevi
2016-06-17 01:38
@garisingh, @binhn, @sheehan, @cbf: just a quick one to gauge the appetite for merging 1799 ?


ranga
2016-06-17 02:09
@muralisr Thanks !

binhn
2016-06-17 04:02
@jonathanlevi: i merged 1799; just 1 comment for next time that a pr should contain only what it says. This one contains many other unrelated commits, but I let it go

jonathanlevi
2016-06-17 04:04
Thank you @binhn - will make sure that the message will get through...

jonathanlevi
2016-06-17 04:05
+ another thanks for approving this so close to the weekend !

grapebaba
2016-06-17 05:26
latest master seems have compile error


simon
2016-06-17 11:14
master build is broken

santhoshr
2016-06-17 12:00
has joined #fabric-dev

simon
2016-06-17 13:31
can everybody build master?

simon
2016-06-17 13:31
i get a build failure in tca.go

simon
2016-06-17 13:32
had to do this: ``` modified membersrvc/ca/tca.go @@ -41,7 +41,7 @@ import ( "http://golang.org/x/net/context" "http://google.golang.org/grpc" - "google/protobuf" + protobuf "google/protobuf" ) var ( @@ -305,7 +305,7 @@ func (tcap *TCAP) requestAttributes(id string, ecert []byte, attrs []*pb.TCertAt } req := &pb.ACAAttrReq{ - Ts: &google_protobuf.Timestamp{Seconds: time.Now().Unix(), Nanos: 0}, + Ts: &protobuf.Timestamp{Seconds: time.Now().Unix(), Nanos: 0}, Id: &pb.Identity{Id: id}, ECert: &pb.Cert{Cert: ecert}, Attributes: attrNames, ```

ghaskins
2016-06-17 13:32
@simon: ill try it in a second, but that strikes me as a potential protobuf environment type thign

ghaskins
2016-06-17 13:33
are you still running outside vagrant?

simon
2016-06-17 13:33
i am

ghaskins
2016-06-17 13:33
my guess is that is related

ghaskins
2016-06-17 13:33
but let me try to build HEAD

ghaskins
2016-06-17 13:36
@simon: running a build now…in the meantime, can you describe your environment in terms of OS/protobufs

ghaskins
2016-06-17 13:36
e.g. Ubuntu 14.04? protobuf 3.0.0-beta3?

simon
2016-06-17 13:36
well, the protobuf is vendored

ghaskins
2016-06-17 13:36
not fully

ghaskins
2016-06-17 13:37
protoc is an external package, it might influence some of it

ghaskins
2016-06-17 13:39
I just pulled HEAD and ran “make clean peer”, it ran fine

ghaskins
2016-06-17 13:39
is that the wrong target?

simon
2016-06-17 13:39
yes

simon
2016-06-17 13:39
membersvc

ghaskins
2016-06-17 13:39
gotcha, let me try that

ghaskins
2016-06-17 13:40
also ran fine

simon
2016-06-17 13:40
how, why?

simon
2016-06-17 13:41
tca.go uses both protobuf and google_protobuf packages

simon
2016-06-17 13:41
but it doesn't import them properly

ghaskins
2016-06-17 13:42
the relationship between the go protobuf stuff and the external protobuf installation is a little murky to me, but one thing I do know is I think the Timestamp scalar is a bit unusual in that it seems to be defined in a extesion package (timestamp.proto)

ghaskins
2016-06-17 13:42
so, my guess is you somehow have a timestamp.proto in your environment that is different from what the normalized environment is expecting

ghaskins
2016-06-17 13:42
that is just a guess though

ghaskins
2016-06-17 13:43
what line is that snippet on?

ghaskins
2016-06-17 13:43
i can see what mine looks like

ghaskins
2016-06-17 13:43
nevermind, i see the context when I scroll further

ghaskins
2016-06-17 13:45
the logic in question was added as part of commit 780f001d

ghaskins
2016-06-17 13:45
with a date of 5-24-16, though sometimes git lies about that so let me confirm



ghaskins
2016-06-17 13:47
It does seem to build fine for me, as well as not breaking CI, so I suspect you have some kind of issue with your protobuf install

simon
2016-06-17 13:48
something is fishy

simon
2016-06-17 13:48
it should all come from vendored code, no?

ghaskins
2016-06-17 13:48
no, see above

ghaskins
2016-06-17 13:49
err, i should say “I dont know, its complicated” heh

ghaskins
2016-06-17 13:49
theres protoc/libprotobuf.so type stuff that is out of the go/vendoring domain

ghaskins
2016-06-17 13:49
I think timestamp.proto comes as part of that (though I am not sure either)

ghaskins
2016-06-17 13:50
just speculating based on the fact that I have seen timestamp.proto in other contexts, vagrant works, and yours doesnt

binhn
2016-06-17 13:50
@simon: fixed in #1888 — pull the master again

simon
2016-06-17 13:50
binhn: ah, ok

ghaskins
2016-06-17 13:50
or, theres that possibility, heh

simon
2016-06-17 13:50
ha!

simon
2016-06-17 13:51
i thought i was going crazy :slightly_smiling_face:

binhn
2016-06-17 13:51
something wrong when i merged 1799 last night that I haven’t chased down

binhn
2016-06-17 13:51
1799 passed CI but introduced build problems (protobuf) in the master

ghaskins
2016-06-17 13:52
@simon: what sha are you on right now?

ghaskins
2016-06-17 13:52
now im curious what the diff was

simon
2016-06-17 13:52
now i pulled

ghaskins
2016-06-17 13:52
ah, oh well

simon
2016-06-17 13:53
master changed between me finding the issue and east coast waking up :slightly_smiling_face:

ghaskins
2016-06-17 13:58
now thats fast turnaround

ghaskins
2016-06-17 13:58
precog bug fixing

ghaskins
2016-06-17 13:59
“Anomalous behavior predicted and repaired, Dave. Please pull master"

jonathanlevi
2016-06-17 14:03
Good morning (from the West Coast)!

jonathanlevi
2016-06-17 14:04
@simon: Yeah, I can say that same thing from here

jonathanlevi
2016-06-17 14:04
BTW: feel free to @ JonathanLevi (tag) me... so that I get notified (after hours)

jonathanlevi
2016-06-17 14:04
Having a quick look.

jonathanlevi
2016-06-17 14:09
@ghaskins, @simon, @binhn: OK, I see the problem.

jonathanlevi
2016-06-17 14:09
Indeed, all the PR tests pass.


ghaskins
2016-06-17 14:09
@jonathanlevi: im confused, IIUC the bug is already fixed

jonathanlevi
2016-06-17 14:10
Yes, I know. But I want to look at WHY it happened :wink:

jonathanlevi
2016-06-17 14:10
(as in, how come the build for the PR was Green, but after auto-merging, master started failing)

jonathanlevi
2016-06-17 14:10
Binhn did merge a 'passing/Green' PR

ghaskins
2016-06-17 14:11
Ah, gotcha

ghaskins
2016-06-17 14:13
one plausible scenario we can have today with the CI model is, a) submit PR, passes CI, b) some other PR gets merged to master, c) (a) gets merged and conflicts with (b)

ghaskins
2016-06-17 14:13
what would be awesome is if we could have some intelligence to detect that outstanding PR builds need to respin every time master is updated

jonathanlevi
2016-06-17 14:13
Yeah, as this grows, I'd appreciate a `staging` branch!

jonathanlevi
2016-06-17 14:14
@cbf: But I don't want to volunteer for this one... because it's probably a lot of work :wink:

jonathanlevi
2016-06-17 14:14
So that issues/PRs can merge only after a day/week in staging...

simon
2016-06-17 14:15
why staging?

jonathanlevi
2016-06-17 14:15
We can discuss it at some point.

simon
2016-06-17 14:15
way too much work

jonathanlevi
2016-06-17 14:15
(sorry, we wrote at the same time)

simon
2016-06-17 14:15
we already only have 2-3 committers

jonathanlevi
2016-06-17 14:15
Way too much work, I agree.

simon
2016-06-17 14:15
you'd double the work and the opportunity for conflicts

jonathanlevi
2016-06-17 14:17
"jonathanlevi: 7:13 AM Yeah, as this grows, I'd appreciate a staging branch!"

jonathanlevi
2016-06-17 14:17
@simon: Yeah, not saying we are there yet.

jonathanlevi
2016-06-17 14:17
Code-wise, I think I know what happened though.

jonathanlevi
2016-06-17 14:18
Looking at the code, we have conflicting import aliases... and the (unit) test/compilation order made/makes a difference.

jonathanlevi
2016-06-17 14:19
First of all, @grapebaba: thanks for the quick fix.

jonathanlevi
2016-06-17 14:19
Second, I'll suggest a fix in my next PR.

jonathanlevi
2016-06-17 14:20
(I know that master is fine now, but just to prevent it from re-occurring in the future)

simon
2016-06-17 14:21
but why did CI pass?

jonathanlevi
2016-06-17 14:23
You mean, with the PR ?

jonathanlevi
2016-06-17 14:23
Pass as in the CI build of the PR, or of `master` ?

simon
2016-06-17 14:25
isn't that the same?

jonathanlevi
2016-06-17 14:26
Sorry. I'm lost :slightly_smiling_face:. Here's the problem that I'm looking at: 1. PR 1799's build is Green 2. `master` pre-merge of PR 1799 is Green 3. Merge PR 1799 into master: compilation error

jonathanlevi
2016-06-17 14:26

jonathanlevi
2016-06-17 14:26
All the PR tests were Green.

cbf
2016-06-17 14:28
typically, we would have jenkins be the final arbiter on a merge with master... 2 +2 in gerrit from committers drives a final build and if that passes it is merged or else reverts to rebase and try again

cbf
2016-06-17 14:28
@jonathanlevi: @ghaskins @sheehan @binhn @tamas @ry @bramwelt ^^

cbf
2016-06-17 14:29
@ramesh: ^^

bramwelt
2016-06-17 14:29
has joined #fabric-dev

ry
2016-06-17 14:29
has joined #fabric-dev

jonathanlevi
2016-06-17 14:29
That way `master` will always build, and we can auto-reject ANY failing process.

cbf
2016-06-17 14:29
yes

cbf
2016-06-17 14:30
bbl

simon
2016-06-17 14:30
well merged...

simon
2016-06-17 14:30
it should be merged, and then it should test

simon
2016-06-17 14:30
and then master can be updated

simon
2016-06-17 14:30
you need to test the merged version, not the unmerged branch

jonathanlevi
2016-06-17 14:31
In `staging`, yes.

simon
2016-06-17 14:31
why staging?

jonathanlevi
2016-06-17 14:31
(btw: I don't know if this is how you guys want to refer to it)

jonathanlevi
2016-06-17 14:31
It's one extra step before master.

simon
2016-06-17 14:31
but why?

jonathanlevi
2016-06-17 14:33
@simon: "Why= why do I suggest to have a branch that we merge to before going straight to master" ?

simon
2016-06-17 14:33
yes

jonathanlevi
2016-06-17 14:34
Because then: 1) nobody can break master

jonathanlevi
2016-06-17 14:34
2) merging becomes a very linear process

jonathanlevi
2016-06-17 14:34
3) reverting is immediate

jonathanlevi
2016-06-17 14:35
4) we won't have the issue we had last weekend when we continued to look at Red PRs, and it took time to figure out who's fault it is, etc.

jonathanlevi
2016-06-17 14:35
5) all conflicts will be resolved on that branch

simon
2016-06-17 14:36
now you just shifted the problem to the staging branch

simon
2016-06-17 14:36
i don't see how another branch will change anything

simon
2016-06-17 14:37
everybody will have to develop on staging then

simon
2016-06-17 14:37
or conflicts will be even worse

jonathanlevi
2016-06-17 14:37
Well, it depends on the staging time

simon
2016-06-17 14:37
wouldn't it be easier to run CI on the proposed merge commit?

jonathanlevi
2016-06-17 14:38
It can be immediate (e.g., per PR)

jonathanlevi
2016-06-17 14:38
So we can either have staging, where we wait to see what's happening before even submitting a PR

jonathanlevi
2016-06-17 14:38
Or we can have a process where we merge first, then submit the PR for review.

simon
2016-06-17 14:40
that doesn't work, because that will only work for one PR

jonathanlevi
2016-06-17 14:40
Which one?

simon
2016-06-17 14:40
the first

binhn
2016-06-17 14:40
@jonathanlevi: isn’t that what @cbf said about Jenkins process: merge with master then build rather than just building the PR branch. That would prevent what happened last night with 1799

simon
2016-06-17 14:40
all other PRs then will require a new merge

jonathanlevi
2016-06-17 14:40
@binhn: yes.

jonathanlevi
2016-06-17 14:40
That's my understanding.

binhn
2016-06-17 14:41
i know folks are working on getting Jenkins integrated but not there yet

jonathanlevi
2016-06-17 14:42
@binhn: Sounds good. @simon, I would like to continue the discussion about a `staging` branch, separately.

jonathanlevi
2016-06-17 14:43
I probably don't explain myself well. I do think that you will like it (I should start with requirements first, of course, as in tackling the; `Jon, why even bother doing that!?` ;-)

jonathanlevi
2016-06-17 14:43
---

jonathanlevi
2016-06-17 14:46
OK, back to the code. Why is `tca.go` using a package (alias) that it's not importing directly in the first place?! :wink:

jonathanlevi
2016-06-17 14:47
Here's the culprit (I betcha not going to like it!) Our good ol' `tca.go` was/is using an import (alias) that is actually defined in a (unit) test file!

jonathanlevi
2016-06-17 14:48
After merge (in master) the order seems to have changed.

ghaskins
2016-06-17 15:09
@sheehan: 1882 clear to go in from your perspective?

ghaskins
2016-06-17 15:09
Its passing CI, so I think the answer is “yes” but just wanted to check

sheehan
2016-06-17 15:09
yes

ghaskins
2016-06-17 15:09
10-4

sheehan
2016-06-17 15:09
thanks

ghaskins
2016-06-17 15:09
done, and thanks

ghaskins
2016-06-17 15:10
this will help a lot

ghaskins
2016-06-17 15:10
does that conclude the current effort to automate the linters, or are there more queued up?

sheehan
2016-06-17 15:11
that’s it for now. I don’t plan to include `golint` due to the false positives we discussed

arnaud
2016-06-17 18:43
hi there

arnaud
2016-06-17 18:44
I found out that we have 40 different loggers in our code, is that really reasonable/desirable?

arnaud
2016-06-17 18:45
you can get the list with a simple git grep MustGetLogger *go

arnaud
2016-06-17 18:47
is it standards practice for go development to have a different logger for every package?

ghaskins
2016-06-17 18:55
@arnaud: this is my first major golang project, so I can’t comment on what is idiomatic in golang per se, but I can say I’ve seen plenty of other environments where that is common practice

ghaskins
2016-06-17 18:55
it allows you to have fairly fine grained control on logging levels in the places where ive seen that

arnaud
2016-06-17 18:56
that's true

arnaud
2016-06-17 18:57
except that getting them set to the level you want isn't so easy

ghaskins
2016-06-17 18:57
well, thats a different matter, heh

arnaud
2016-06-17 18:57
I found that you can set any of them through the use of the --logging-level Bishop developed

ghaskins
2016-06-17 18:57
honestly its not always about the granularity of the control as it is with the granularity of the output context

arnaud
2016-06-17 18:57
but most of them aren't settable via yaml

arnaud
2016-06-17 18:58
yes, I agree

ghaskins
2016-06-17 18:59
for instance, if you only had a top level object, you might be explicitly adding context at each callsite Log(“foo/bar/baz: Error opening file”) as opposed to bazlogger.Error(“open failure”):

arnaud
2016-06-17 19:01
well, the logger standard format gives some of that as they display the name of the logger

ghaskins
2016-06-17 19:01
yeah, i dont know much about it in this case

arnaud
2016-06-17 19:01
as in 16:36:47.078 [main] serve -> INFO 004 Disable loading validity system chaincode

ghaskins
2016-06-17 19:01
just doesnt strike me as overtly bad

arnaud
2016-06-17 19:02
the name in [] is the name of the logger

arnaud
2016-06-17 19:02
and from there you can find the package it corresponds to

arnaud
2016-06-17 19:03
if you want to change the level you'd have to do --logging-level="main=DEBUG" for instance

arnaud
2016-06-17 19:04
for some of them you can also set it in the yaml file

arnaud
2016-06-17 19:04
nowhere that I saw this is documented though

arnaud
2016-06-17 22:22
to be more precise, there is some documentation of this but even the doc recognizes its limit when it states that:An arbitrary number of logging modules can be created at runtime, therefore there is no "master list" of modules, and logging control constructs can not check whether logging modules actually do or will exist.

arnaud
2016-06-17 22:23
we've got to do better than that

binhn
2016-06-17 23:27
@tuan @jyellick @bmos299 CI failed on #1877

jyellick
2016-06-17 23:27
I'll take a look

jyellick
2016-06-17 23:32
On my phone, apparently can't see Travis status without logging in, but will address it when I get back to my laptop

ramesh
2016-06-17 23:47
Please refer issue#1907

binhn
2016-06-18 01:40
i am trying pr 1877 locally since i don’t understand why db failed

binhn
2016-06-18 02:04
got same error posted in issue 1907

jonathanlevi
2016-06-18 02:32
Have a good weekend fabric-dev!

binhn
2016-06-18 12:58
@bmos299: @jyellick: I merged pr 1877. Thanks Jason.

basav
2016-06-18 15:17
has joined #fabric-dev

hgabor
2016-06-20 08:34
https://github.com/hyperledger/fabric/pull/1754 I have a strange error here: Error opening DB IO error: lock /var/hyperledger/test/ledger_test/db/LOCK: Resource temporarily unavailable Isn't this a Jenkins/environment problem? Can somebody take a look?

ry
2016-06-20 08:43
@hgabor: this is an ongoing issue, I’m not sure who is working on it

hgabor
2016-06-20 08:47
@ry: thanks

zuowang
2016-06-20 09:30
@zuowang uploaded a file: https://hyperledgerproject.slack.com/files/zuowang/F1JAWEW1H/_____________20160617150935.png and commented: I am taking a look at chaincode example asset_management.go. It uses the same TCert all the time. Then I found a way in protocol-spec.md to address this problem. But is it implemented now in fabric? I didn't find api access to TCert from client side, how can I construct a transaction like that?

zuowang
2016-06-20 09:41
reflect.DeepEqual takes as high as 8.3% of total cpu time and it's in a critical path(in the call path to commit reqs, which is linear(anyone tell me why?)). I believe the throughput would be much better if we can do it more efficiently. consensus/obcpbft/obc-batch.go:211 // TODO, this is a really and inefficient way to do this, but because reqs aren't comparable, they cannot be retrieved from the map directly for oreq := range op.outstandingReqs { if reflect.DeepEqual(oreq, req) { delete(op.outstandingReqs, oreq) break } }

simon
2016-06-20 09:47
zuowang: you are right

simon
2016-06-20 09:47
i'll work on a fix

yacovm
2016-06-20 11:21

virajkamat
2016-06-20 12:04
has joined #fabric-dev

yacovm
2016-06-20 13:14
Hey, I'm running a test with PBFT-batch in which I deploy a CC (example 2 from github): ``` "ctorMsg": { "function":"init", "args":["a", "5000", "b", "0"] } ``` with invoke: ```` "ctorMsg": { "function":"invoke", "args":["a", "b","1"] } ``` So after 5000 invocations, all A has to get to B, but when I do a query I get: ``` Query Response:{"Name":"a","Amount":"3902"} ``` constantly, which means - it doesn't really work. When I re-run, sometimes it gets to 0, but sometimes it gets stuck.... Is there any known of issue of things like that?

ghaskins
2016-06-20 13:16
@yacovm: are you confirming each invoke or otherwise implementing flow control?

simon
2016-06-20 13:16
you need to run in closed loop

ghaskins
2016-06-20 13:17
agree with @simon

simon
2016-06-20 13:17
most likely most of your invokes are being discarded because you overload the system

yacovm
2016-06-20 13:17
yeah, if some invocation returns a non 200 return code I don't continue sending. I've also never seen such a case in which the invocation returned a non 200 code

simon
2016-06-20 13:17
nono

yacovm
2016-06-20 13:17
oh I see

simon
2016-06-20 13:17
the 200 is just about the request being accepted initially

ghaskins
2016-06-20 13:18
@yacovm: return code isn’t enough as the system is async…you have to wait for confirmation technically...

simon
2016-06-20 13:18
i implemented that long ago - i think we need to really do this

ghaskins
2016-06-20 13:18
one problem right now (that is being actively worked on) is ascertaining status of a txn isnt as easy as it needs to be

simon
2016-06-20 13:18
people get confused

yacovm
2016-06-20 13:18
when do we drop requests?

yacovm
2016-06-20 13:18
In the code I've never seen such a thing that "drop this request if we're overloaded"

simon
2016-06-20 13:18
well we shouldn't drop requests

simon
2016-06-20 13:18
and that is a problem

yacovm
2016-06-20 13:18
but where do we do that?

yacovm
2016-06-20 13:19
the request gets into the consensus and into that events.go shared channel

simon
2016-06-20 13:19
because if we don't drop them, they are stored somewhere in memory

yacovm
2016-06-20 13:19
of course

yacovm
2016-06-20 13:19
but, I thought that dropping requests isn't implemented

yacovm
2016-06-20 13:20
is it implemented? if yes- where, if you can spare the time to say

simon
2016-06-20 13:20
we drop messages

simon
2016-06-20 13:20
but we should be retrying requests

yacovm
2016-06-20 13:20
you drop messages... where? how?

yacovm
2016-06-20 13:20
(code wise)

simon
2016-06-20 13:20
messages are dropped in broadcaster

simon
2016-06-20 13:21
or are they

simon
2016-06-20 13:21
hmm

simon
2016-06-20 13:21
i think what we really need is statistics on all these things

yacovm
2016-06-20 13:21
can you say where in the code?

simon
2016-06-20 13:22
dropped (if we can tell), and queued requests

simon
2016-06-20 13:22
hm maybe we don't drop?

simon
2016-06-20 13:23
yea i think we don't

ghaskins
2016-06-20 13:23
@simon: if we don’t, we need to

simon
2016-06-20 13:23
i wrestled with channels

simon
2016-06-20 13:23
and had problems testing it

ghaskins
2016-06-20 13:23
it could simply be that his observation of incomplete status is at least partially because the queue hasnt completed

simon
2016-06-20 13:23
so i rewrote it

simon
2016-06-20 13:23
and i think now we don't drop unless grpc fails

ghaskins
2016-06-20 13:23
(and/or stalled)

yacovm
2016-06-20 13:23
:neutral_face: If we don't drop, then where do they disappear to?

simon
2016-06-20 13:24
yacovm: i don't know

simon
2016-06-20 13:24
yacovm: i think now is the time to add statistics

ghaskins
2016-06-20 13:24
sounds like a potential bug…though that said, blind submission without confirmation is just asking for trouble

simon
2016-06-20 13:24
ghaskins: what do you think, how should we do statistics?

simon
2016-06-20 13:25
have a goroutine process that triggers updates?

yacovm
2016-06-20 13:25
@ghaskins: - how do I submit non-blindly?

simon
2016-06-20 13:25
or do we register pointers to integers and serve those directly

ghaskins
2016-06-20 13:25
@simon: the way I usually do it is to optimize the fast path

ghaskins
2016-06-20 13:25
yeah, thats what I would recommend

ghaskins
2016-06-20 13:25
let the fast path have direct access, query path can be indirect

ghaskins
2016-06-20 13:26
it often means aggregation isnt wholly accurate/syncrhonized, but who cares

ghaskins
2016-06-20 13:26
(I should’t say “who cares”, but what I mean is, the trade off is worth it

simon
2016-06-20 13:26
yes

ghaskins
2016-06-20 13:27
often times you are just looking for general velocity

simon
2016-06-20 13:27
i shall do this after benchmarking this requeststore thing

simon
2016-06-20 13:27
would you also do derivatives?

ghaskins
2016-06-20 13:27
not sure what you mean

simon
2016-06-20 13:27
well, requests/sec

simon
2016-06-20 13:27
instead of total numbers

ghaskins
2016-06-20 13:28
oh, yes I typically include those but often times its better to do them in the client

ghaskins
2016-06-20 13:28
stats client, i mean

yacovm
2016-06-20 13:28
soooo... ummm back to my question, what would you suggest me to do, in order to have 0 "dropped"/"disappeared" messages? increase the time between concurrent invocations and hope for the best?

simon
2016-06-20 13:29
i wonder whether there are telemetry libs

simon
2016-06-20 13:29
that we can use

ghaskins
2016-06-20 13:29
@yacovm: for the long term solution, what you should do is hook into the event channel for confirmation, and implement a sliding window so you are never more than N outstanding

simon
2016-06-20 13:29
yacovm: wait until there is an event for the transaction

simon
2016-06-20 13:29
yea that's what i did

yacovm
2016-06-20 13:29
I thought the event channel isn't implemented yet?

ghaskins
2016-06-20 13:29
for the short term, the event channel isnt fully baked so you’ll have to fake flow control

yacovm
2016-06-20 13:29
yeah I get you

ghaskins
2016-06-20 13:30
you can do that in various ways, the cheesiest/quickest is to just artificially slow things down


yacovm
2016-06-20 13:35
why haven't you merged it, if it was done long ago?

simon
2016-06-20 13:36
it's a bad hack :slightly_smiling_face:

yacovm
2016-06-20 13:44
well, I put a 500 millis delay between 2 consequent requests, and it's stuck on 3813 now. I don't think it was because of too many requests queued.

bcbrock
2016-06-20 13:46
@yacovm Look in the peer logs, you may find ERRO messages about the peers dropping transactions because the queues are full

simon
2016-06-20 13:47
yacovm: if the network seems stuck, submit a single request and capture the logs

bcbrock
2016-06-20 13:47
PBFT Batch is not fully functional yet either, see issue #1857

ghaskins
2016-06-20 13:48
Yeah, first thing to figure out is, does it miss some transactions but catch others (flakey) or stop completely (stall)

simon
2016-06-20 13:48
i thought all bugs were fixed?

yacovm
2016-06-20 13:48
no such errors in the logs, and the network isn't stuck... it can't be, it's on the same node

bcbrock
2016-06-20 13:48
@simon Not yet

simon
2016-06-20 13:48
that seems like a state transfer issue

ghaskins
2016-06-20 13:49
By "stuck" we mean is it still processing some transactions or stalled completely

tuand
2016-06-20 13:50
@bcbrock: have you looked at @jyellick 's PR #1877 ?

yacovm
2016-06-20 13:51
ok ok my bad about after adding the 500 millis timeout thing, I had an auto-suicide timer in the script after enough time, forgot to turn it off after I significantly raised the total running time :cold_sweat:

simon
2016-06-20 13:51
hehe

bcbrock
2016-06-20 13:53
@tuand Jason is aware of issue #1857 and never suggested to me that #1877 would fix it, but I can try it later today

jyellick
2016-06-20 13:54
@bcbrock: 1877 should actually fix 1857, however, I found a different bug which is currently causing problems for busywork, (1917), if you find that buswork times out without successfully deploying, I can give you a workaround

simon
2016-06-20 13:55
what's the cause for that?

simon
2016-06-20 13:55
the view change lock?

jyellick
2016-06-20 13:55
Right

jyellick
2016-06-20 13:56
(@bcbrock I referenced 1857 in 1877 as fixed, I can also post it to the issue next time if you'd prefer)

bcbrock
2016-06-20 13:59
Please - that way I’m sure to get an email when the issue is fixed

jyellick
2016-06-20 13:59
Sure thing, sorry for the confusion

simon
2016-06-20 13:59
ghaskins: what's the policy of using other libraries?

ghaskins
2016-06-20 14:00
@simon: first off: “I dont know” :wink: Second, can you provide more context?

ghaskins
2016-06-20 14:00
are you talking about golang packages, etc?

arnaud
2016-06-20 14:00
hi all, no fabric call today?

simon
2016-06-20 14:00
yes

ghaskins
2016-06-20 14:01
policy wise, I am not sure…technically, I know we use govendor generally as the primary mechanism

arnaud
2016-06-20 14:01
ah, I got the invite

ghaskins
2016-06-20 14:03
@simon: personally, I am a big fan of reusing quality libraries, so I welcome it with the caveat that IANAL

simon
2016-06-20 14:05
ok


dmurik
2016-06-20 21:24
@simon: re: telemetry code - have you considered using a statsd client inside fabric, and then running a (local) statsd server (which can be any statd implementation)? statsd then supports multiple backends to which you can pour the metrics.

binhn
2016-06-20 22:16
Announcing Hyperledger Fabric release v0.5-developer-preview https://github.com/hyperledger/fabric/wiki/Fabric-Releases

bcbrock
2016-06-20 22:44
@jyellick Yes, please provide the workaround you mentioned above for #1917

bcbrock
2016-06-20 22:46
I’ve tried adding sleeps between network deployment and starting the tests with mixed success.

jyellick
2016-06-21 00:14
@bcbrock You can use PR 1927 or increase the wait time after starting the peers before issuing the first request

jyellick
2016-06-21 00:17
You may see duplicated requests, that is a side effect of the latest broadcasting changes, fix in progress for tomorrow

hgabor
2016-06-21 07:35
hi all

hgabor
2016-06-21 07:35
https://github.com/hyperledger/fabric/pull/1722 https://github.com/hyperledger/fabric/pull/1719 can somebody check those? :slightly_smiling_face: there are some issues that need to be solved and I would need some other opinion :slightly_smiling_face:

nashikkarh
2016-06-21 08:44
has joined #fabric-dev

deeflorian
2016-06-21 11:35
has joined #fabric-dev

simon
2016-06-21 13:41
```ESC[36m13:38:25.102 [chaincode] Launch -> DEBU 4e3ESC[0m launchAndWaitForRegister failed Error starting container: Post http://172.17.0.1:2375/containers/create?name=dev-vp1-a5389f7dfb9efae379900a41db1503fea2199fe400272b61ac5fe7bd0c6b97cf10ce3aa8dd00cd7626ce02f18accc7e5f2059dae6eb0786838042958352b89fb: dial tcp 172.17.0.1:2375: i/o timeout```

simon
2016-06-21 13:41
what's going on there?

simon
2016-06-21 13:41
seems my docker doesn't react?

simon
2016-06-21 13:41
weird

muralisr
2016-06-21 13:51
@simon, from the message, seems to come from the docker client … unable to work with the docker daemon for some reason ?

simon
2016-06-21 13:51
something about firewall i guess?

muralisr
2016-06-21 13:52
that would fit I suppose

muralisr
2016-06-21 13:53
perhaps a GET with "curl http://172.17.0.1:2375/containers/…." ?

satheesh
2016-06-21 15:22
I get these errors when running behave tests


satheesh
2016-06-21 15:22
`15:19:41.543 [dockercontroller] Start -> ERRO 07b start-could not recreate container cannot connect to Docker endpoint`

simon
2016-06-21 15:31
make sure that your docker daemon is listening on the port

kostas
2016-06-21 16:05
can the Peer persist data to the DB as things stand right now? I was looking for something similar to what the `consensus` package does with the validator https://github.com/hyperledger/fabric/blob/master/consensus/helper/persist/persist.go

kostas
2016-06-21 16:18
if there's no such functionality, shall we bring this package down to the peer level, while making the key prefix (currently set to `consensus.`) a variable?

simon
2016-06-21 16:19
well, just use the db stuff?

simon
2016-06-21 16:20
or move it

simon
2016-06-21 16:21
i think the persist interface is nicer

kostas
2016-06-21 16:21
I think so as well

simon
2016-06-21 16:21
but barely different

kostas
2016-06-21 16:22
this will be needed for #1874, unless you have a different take on how the rootNodes list should be persisted

simon
2016-06-21 16:23
i suggest configuring it statically for now

ghaskins
2016-06-21 16:23
@binhn @sheehan @ramesh trying to untangle a potential discrepancy between the developer preview branch and tag

ghaskins
2016-06-21 16:24
its a little confusing via the github interface, i need to dig in with command line to figure out what happened…but it _looks_ like we might have two different branch points

kostas
2016-06-21 16:24
so: vp0, vp1, vp2, vp3 all do `CORE_PEER_DISCOVERY_ROOTNODE=vp0:30303,vp1:30303, etc.`?

ghaskins
2016-06-21 16:26
For instance, here: https://github.com/hyperledger/fabric/releases shows the tag as 6905fec whereas the branch shows 72a7cbf

ghaskins
2016-06-21 16:27
im guessing that the branch/commit/tag sequence interleaved

ghaskins
2016-06-21 16:27
but in addition, it seems that travis is very confused by the tag

bcbrock
2016-06-21 19:19
@jyellick In your comments above are you suggesting that issue #1931 is expected?

jyellick
2016-06-21 19:22
@bcbrock This is a known limitation/bug at the moment, we are working on a solution

jyellick
2016-06-21 19:24
We discussed some earlier today in #, but the correct way to fix it isn't immediately obvious, or necessarily trivial

bcbrock
2016-06-21 19:26
Regarding #1857 I am trying to reproduce. The “stuck” peers may have been experiencing buffer overflows.

bcbrock
2016-06-21 19:27
Queue overflows actually

jyellick
2016-06-21 19:29
@bcbrock: The short explanation of 1931 is that when it takes longer for a broadcast message to go from say vp1 to vp3, than for that same message to from vp1 to vp0, plus have vp0,vp2,vp3 do the three phase message exchange, then you may see duplicated requests. This obviously needs to be fixed, but it is hopefully an unlikely real life network latency scenario.

bcbrock
2016-06-21 19:37
I thought the protocols were formally verified?

jyellick
2016-06-21 19:41
They are, but in adapting it for our use case, there are some deviations. The protocol spec indicates that clients should wait for a response to their request before submitting a new one. This allows for clean deduplication without risk of censorship. But, we expect this would be unacceptable for our throughput in the long term, so we are trying to come up with a better solution.

bcbrock
2016-06-21 19:43
Interesting. I will put this to the test by having 1000 clients all sending and waiting for 1 TX at a time.

jyellick
2016-06-21 19:44
@bcbrock This is client in terms of the paper

jyellick
2016-06-21 19:44
So, for us, each VP is a client

bcbrock
2016-06-21 19:44
You are right, not interesting as a product.

jyellick
2016-06-21 19:47
In the paper, clients submit PBFT requests directly to the network, in fabric, we receive something like a REST request, and then act like a client in submitting it to the PBFT network. There are some avenues to scale this, and I'm certain it can be worked around, but as I said, the solution is non-obvious

bcbrock
2016-06-21 20:00
@jyellick I just updated #1857 with debug logs from a “stuck” run of stress2b

jyellick
2016-06-21 20:01
@bcbrock https://github.com/hyperledger/fabric/pull/1941 This should be an effective workaround for the time being to remove those duplicate requests, until we can come up with a better solution

jyellick
2016-06-21 20:18
Also see what is going on with 1857, replied to you in the issue

nashikkarh
2016-06-22 12:10
Hi, I'm trying to start the node first time using "docker run --name CA_test_node --rm -it -p 5000:5000 -p 30303:30303 -e CORE_PEER_ID=vp0 -e CORE_VM_ENDPOINT=http://172.17.0.1:4243 -e CORE_PEER_ADDRESSAUTODETECT=true hyperledger-ca-peer:version1 peer node start" but getting below error " 2016/06/22 12:01:13 Failed to listen: listen tcp: lookup vp0 on 10.0.2.3:53: no such host" ... can anyone pls advise how to fix this. Is this an issue with core.yaml?

jeffgarratt
2016-06-22 14:38
@nashikkarh: this is failing trying to start the GRPC server

jeffgarratt
2016-06-22 14:39
not sure I recognize the docker image you are using

ghaskins
2016-06-22 16:01
@nashikkarh: it seems you are using a dns hostname of “vp0” which is not known to the DNS server configured at 10.0.2.3

ghaskins
2016-06-22 16:02
try changing CORE_PEER_ID perhaps, or update your dns server

ghaskins
2016-06-22 16:02
(Im not sure of CORE_PEER_ID drives a dns lookup, but that is my only guess based on the info provided

brendan
2016-06-22 19:42
has joined #fabric-dev

kostas
2016-06-22 22:19
am I the only one seeing occasional failures on the `custodian` unit tests?

nhrishi
2016-06-23 04:19
has joined #fabric-dev

nashikkarh
2016-06-23 06:37
@ghaskins: Thanks !! changing CORE_PEER_ID helped...its starting the node now.

nashikkarh
2016-06-23 06:38
Thanks @jeffgarratt

zuowang
2016-06-23 06:48
protos/chaincode.pb.go:101 What are these two ChaincodeMessage_Type "PUT_STATE" and "DEL_STATE" used for? Thanks!

yacovm
2016-06-23 07:43
I'd assume they represent shim/chaincode.go's respective methods


zuowang
2016-06-23 09:47
Thanks yacovm

zuowang
2016-06-23 09:47
Why I encountered this error constantly? But it didn't crash. My code base is 6905fec. 07:28:36.465 [consensus/obcpbft] processNewView2 -> CRIT 003 Replica 0 is missing request for assigned prepare after fetching, this indicates a serious bug

yacovm
2016-06-23 09:52
The java chaincode is in development, right? Anyone knows where is its codebase?

dianfu
2016-06-23 09:59
is there any way to add a new column after a table is created?

dianfu
2016-06-23 10:57
Hi, A minor bug (https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/chaincode.go#L715): case *Column_Uint32: keyString = strconv.FormatUint(uint64(key.GetInt32()), 10) should be “(key.GetUint32()"

simon
2016-06-23 11:31
zuowang: can you please submit a bug report?

cbf
2016-06-23 13:46
a PR would be most welcomed:-)

muralisr
2016-06-23 14:07

hgabor
2016-06-23 16:01
how can I disable a bdd test? I do not want to comment it

jeffgarratt
2016-06-23 16:08
@hgabor: add a tag (commonly issue tag) to the scenario, then add that issue to the .behaverc file

jeffgarratt
2016-06-23 16:09
for example, issue_680 is currently disabled by using this mechanism


jonathanlevi
2016-06-23 16:09
@hgabor: please don't abuse this! :wink:

cbf
2016-06-23 16:09
@jeffgarratt: could you please document that in the contributing.md? thx

jeffgarratt
2016-06-23 16:10
@cbf yes

jonathanlevi
2016-06-23 16:10
<amiably> Oh, it used to be Hyperledger Fabric's best kept secret :wink: </amiably>

cbf
2016-06-23 16:11
danke - and add note that we should agree on usage guidelines

cbf
2016-06-23 16:12
eg maybe you need all maintainers to agree or super-majority

jonathanlevi
2016-06-23 16:15
Yes, sounds good. BTW: Whatever (procedure) is decided should probably also apply to `t.Skip()` in the unit tests... though these might be less trivial to flag. @jeffgarratt's file makes it clearer for Behave, as it's easy to view it all in one place... we don't have the same for the skipped unit-tests.

clessor
2016-06-23 17:28
has joined #fabric-dev

zuowang
2016-06-24 00:45
simon


jyellick
2016-06-24 02:24
@zuowang: This error message is benign, and has been fixed

zuowang
2016-06-24 08:08
thanks jyellick


zuowang
2016-06-24 08:12
I found "docker" is the top busy process measured by cpu usage. What kind of business is he doing?

yacovm
2016-06-24 09:56
I don't know, did you try to attach an strace to it and see?

zuowang
2016-06-24 11:20
strace dosen't help:sweat_smile:

satheesh
2016-06-24 12:04
@yacovm: PR has been submitted for the initial java chaincode implementation https://github.com/hyperledger/fabric/pull/1983

yacovm
2016-06-24 12:27
cool

jeffgarratt
2016-06-24 14:31
@zuowang: the daemon may be building the images for chaincodes if you are running a network and deployments are under way. This will of course be the case if you are running the behave tests.

arnaud
2016-06-24 16:17
hi there

arnaud
2016-06-24 16:17
I updated my repo to the latest on master and I see several failures in make checks

arnaud
2016-06-24 16:18
I also see that about all current PRs are reported to fail

arnaud
2016-06-24 16:18
what's going on?

ghaskins
2016-06-24 16:36
@arnaud: can you be more specific?

ghaskins
2016-06-24 16:36
the travis panel looks all green to me

sheehan
2016-06-24 17:06
Jenkins is broken. It’s putting all of those red x’s on the PRs. Travis is passing for many if you look inside the PR

ramesh
2016-06-24 17:11
We are observing build failures in Jenkins with grpcio package error.. Which is resolved in Jenkins x86 machine with PR#1940.

ramesh
2016-06-24 17:12
But we have the same issue Z machines, @jkirke is working on it.

jkirke
2016-06-24 17:12
has joined #fabric-dev

arnaud
2016-06-24 18:00
ah ok, I understand

arnaud
2016-06-24 18:01

arnaud
2016-06-24 18:01
--- FAIL: TestChaincodeInvokeChaincode (38.49s)

kostas
2016-06-24 18:01

arnaud
2016-06-24 18:02

arnaud
2016-06-24 18:02
--- FAIL: TestCreateCertificatePairAdmin (0.00s) eca_test.go:228: Failed to enroll testAdmin: [Identity or token does no

arnaud
2016-06-24 18:02
I have quite a few such failures overall

jeffgarratt
2016-06-24 19:08
FYI: https://github.com/hyperledger/fabric/pull/1940 requires the grpcio python package. You can either manually install this package using the following commands: >pip install --ignore-installed six >pip install 'grpcio==0.13.1'

jeffgarratt
2016-06-24 19:08
Or sync with the latest master and perform a vagrant destroy/up

dmurik
2016-06-24 19:36
Hi, I submitted https://github.com/hyperledger/fabric/pull/2006 which is a possible security issue; I'd appreciate a prompt review if possible. Thanks. Also my commit restricts the allowed pattern for usernames to `\w+` - not sure if it is too restrictive.

sheehan
2016-06-24 20:50
@dmurik: thanks, I’ve added some comments

kostas
2016-06-25 13:43
`make all` on the latest master (`2aeddd`) fails during the `go vet` part


sheehan
2016-06-25 16:06
odd, it passed in CI. https://travis-ci.org/hyperledger/fabric/builds/140129497#L967 Will try to take a look on my local system in a bit

sheehan
2016-06-25 17:12
@kostas: I’ve reverted the PR. I’ll investigate how it was able to get through CI next week

kostas
2016-06-25 17:19
Roger.

zuowang
2016-06-27 00:47
@jeffgarratt: The chaincode was already deployed. The docker daemon was busy while 20 clients were invoking the chaincode.

zuowang
2016-06-27 05:42
@jeffgarratt: perf record -F 99 -p PID -g -- sleep 10 11.58% docker docker [.] runtime.xchg 5.65% docker docker [.] runtime.findrunnable 5.57% docker docker [.] runtime.xadd 5.29% docker docker [.] runtime.lock 3.33% docker docker [.] runtime.procyield


simon
2016-06-27 11:02
oh what is that UI?

zuowang
2016-06-27 11:18
It's qcachegrind. I found the high cpu usage by docker daemon is caused by the verbose log in chaincode.

simon
2016-06-27 11:20
does it use normal go pprof?

ghaskins
2016-06-27 16:00
@muralisr: @sheehan @binhn I whipped up a prototype of the syscc import generation we discussed on the call


ghaskins
2016-06-27 16:00
let me know your thoughts

ghaskins
2016-06-27 16:01
in a nutshell, if you define a list of imports in ./syscc-includes, in adds them to build/syscc/imports.go

ghaskins
2016-06-27 16:01
sorry, .syscc-includes

ghaskins
2016-06-27 16:02
idea being that a fork/local-tree is free to define its own without collisions against upstream

ghaskins
2016-06-27 16:02

binhn
2016-06-27 16:32
@ghaskins: very cool

cbf
2016-06-27 16:34
nice

ghaskins
2016-06-27 16:37
I debate whether .syscc-includes should be in .gitignore

ghaskins
2016-06-27 16:37
on one hand, seeing it in the git-status will be annoying, on the other hand, some use cases will want to check it in to their local fork

ghaskins
2016-06-27 16:38
i’ve erred on the side of the former for now, but I can be convinced either way

ghaskins
2016-06-27 16:38
sorry, ive erred on the side of “no .gitignore, allow local commits"

cbf
2016-06-27 16:52
that will likely mean we have to scan for them on a build and have a whitelist for those we have allowed

ghaskins
2016-06-27 17:05
not sure what you mean

ghaskins
2016-06-27 17:05
isnt the .syscc-includes “the” whitelist

ghaskins
2016-06-27 17:06
BTW one thing I should mention is that upstream can add to this by doing SYSCC_INCLUDE += in the Makefile itself

ghaskins
2016-06-27 17:07
So, Makefile::SYSCC_INCLUDES is upstream list, which is concatenated with .syscc-includes for downstream, to form the complete set

ghaskins
2016-06-27 17:08
only thing _not_ covered there would be upstream components that downstream wants to _exclude_

ghaskins
2016-06-27 17:08
for that, I either need to add something to the design, or they can just edit the makefile

binhn
2016-06-27 17:12
upstream list is good so that folks may just do that instead of having to modify the .syscc-include

muralisr
2016-06-27 17:16
@ghaskins: if I want to enable a test, I’d have to build the image from the whitelist, correct ?

muralisr
2016-06-27 17:17
as opposed to reading a whitelist file at runtime and “enabling” it

ghaskins
2016-06-27 17:17
@muralisr: to be clear, I envision and support the notion of both build-time and run-time whitelist

muralisr
2016-06-27 17:17
ok

ghaskins
2016-06-27 17:17
(though this only covers the build time component of it)

muralisr
2016-06-27 17:18
right

ghaskins
2016-06-27 17:18
I think the run-time part is probably straight forward, though, so I wanted to tackle the bigger gap

muralisr
2016-06-27 17:18
I was just thinking we may need the runtime component too to make it easy for dev/test

muralisr
2016-06-27 17:18
sure

ghaskins
2016-06-27 17:18
yes, agree

muralisr
2016-06-27 17:18
just wanted to make sure I didn’t miss anything

ghaskins
2016-06-27 17:18
nope, you are spot on

ghaskins
2016-06-27 17:19
can probably just have some yaml section for runtime list

ghaskins
2016-06-27 17:19
(or whatever, I have no strong opinion)

simon
2016-06-27 17:19
part of state

simon
2016-06-27 17:19
e.g. initialized in genesis, mutated through chaincode

ghaskins
2016-06-27 17:19
@simon: I know where you are going with that, but not necessarily

ghaskins
2016-06-27 17:20
i think that is part of the story, yes, but not the only

ghaskins
2016-06-27 17:21
“initialization” of these things is def related to ledger history, and at the right moment in time, it should be represented as such

ghaskins
2016-06-27 17:21
this may include genesis or any future block, and be managed as such

ghaskins
2016-06-27 17:22
but the mechanism we are talking about predates the introduction to the ledger

ghaskins
2016-06-27 17:22
consider it the mechanism that makes it available for that step

simon
2016-06-27 17:22
genesis block/genesis state

ghaskins
2016-06-27 17:23
it must not be restricted to genesis only

simon
2016-06-27 17:23
peer genesis $configfile

simon
2016-06-27 17:23
yes, chaincode mutates this state

simon
2016-06-27 17:23
system chaincode

ghaskins
2016-06-27 17:23
maybe we are talking past each other, but IIUC I dont see it quite that way

hgabor
2016-06-27 17:31
I d like to ask a tricky question. Which is that part of the code that is executed right after a consensus is made e.g. pbft or a noops (as far that is a consensus)? If I m right it is exectxs in helper

simon
2016-06-27 17:38
yes

simon
2016-06-27 17:38
why is it tricky?

hgabor
2016-06-27 17:45
Just joking, it is not tricky. :-) so am I right?

hgabor
2016-06-27 18:24
@simon

binhn
2016-06-27 18:27
I generally stay away from disabling something and prefer removing something; the former would require me to check whether something is disabled or enabled, whereas, the latter would just work as expected — if not there, 404 not found.

muralisr
2016-06-27 18:32
@simon @ghaskins the whole point of removing system chaincodes from genesis block was to break that dependency and all the hassle in treating changes to syscc via chaincode upgrades through consensus as opposed to treating changes as part of fabric lifecycle.@simon _e.g. initialized in genesis, mutated through chaincode_ sounded it might bring back those dependencies

ghaskins
2016-06-27 18:33
@muralisr: I agree, (limiting to) genesis block was not the right direction

ghaskins
2016-06-27 18:34
this isnt to say that they cannot appear in genesis, only that they are not required to

yingfeng
2016-06-28 02:56
What's the release plan for the next generation of fabric? https://github.com/hyperledger/fabric/wiki/Fabric-Next And how current branch will evolve due to big changes from fabric next?

dmurik
2016-06-28 14:06
Unit testers out there: when running `go test -v .` (or when a test fails), I see log output in INFO level. Is there a way to set log level to DEBUG for the tests? Setting the env var doesn't work (`viper.AutomaticEnv()` is called from `peer/main.go` which is not running during unit tests). I read documentation in `logging-control.md` but it looks geared towards chaincode developers and the logging of `peer` itself.

bcbrock
2016-06-28 18:00
Is anyone else experiencing problems with the “Custody” tests failing?


bcbrock
2016-06-28 18:02
oops, should have searched for “custodian” instead of “custody” - Thanks

bcbrock
2016-06-28 18:03
@dmurik: I can’t think of a way to do this that does not require modifying some code

kostas
2016-06-28 18:04
(This is a useful framework and one that we may want to reuse in the future in lieu of the naive broadcast that is going on, but I think we may want to remove it until that happens.)

bcbrock
2016-06-28 18:06
@dmurik If the “core” package is being loaded by the test, we could modify init() in core/logging.go to set the default directly from the env. var CORE_PEER_LOGGING_LEVEL (if defined)

hangliu
2016-06-29 23:40
has joined #fabric-dev

castlesb
2016-06-30 14:58
has joined #fabric-dev

mikej
2016-06-30 14:59
has joined #fabric-dev

mikej
2016-06-30 14:59
How sandboxed is the chaincode runtime? Does the runtime _enforce_ that query chaincode functions cannot actually write anything?

ghaskins
2016-06-30 15:28
@mikej: currently the chaincode runs in a somewhat permissive docker container…eventually it will be more restrictive

ghaskins
2016-06-30 15:28
as far as query enforcement, yes, at least w.r.t. fabric state

ghaskins
2016-06-30 15:28
(chaincode only has indirect access to world state via the shim API (e.g. GetState, PutState)

ghaskins
2016-06-30 15:29
it runs in a different process context (and in fact, a docker container) and can only access a) its own portion of world state, and b) during queries, a RO form of it

ghaskins
2016-06-30 15:30
that said, because the container is somewhat permissive right now, the code could conceivably do some form of persistence within a query call within the limits of its docker jail

mikej
2016-06-30 16:11
Thanks @ghaskins , this helps a lot. I don't totally understand the last part of the statement, but this is probably because I'm new at this. Will the "permissive" nature be made more secure in the next ~1/2 year or so? Are PutState calls (direct or indirect) prevented from running during _query_ calls (they would need to work during an _invoke_ call)? Is there documentation somewhere that describes the concurrency/consistency guarantees? For example, imagine a contract that moves/records asset movements from A to B. Now imagine there are two simultaneous invocations of that contract: one moves the balance from alice to bob and the second moves the balance from alice to charlie. What do I need to do as a programmer to make sure that the original asset was not "double spent"?

simon
2016-06-30 16:37
yes, they are rejected for queries

simon
2016-06-30 16:38
there is no simultaneous

simon
2016-06-30 16:38
invokes are serialized

mikej
2016-06-30 16:38
Excellent, thanks.

codascud
2016-06-30 18:27
has joined #fabric-dev

ramesh
2016-06-30 19:23
Unit tests are failing in Jenkins z machines.. Builds are failing consistently. here is the failed build log file.. https://jenkins.hyperledger.org/job/fabric-github-verify-z/332/consoleFull

jeffgarratt
2016-06-30 19:36
@ramesh: this appears to be the unit tests now, correct?

ramesh
2016-06-30 19:36
yes

jeffgarratt
2016-06-30 19:36
k

jonathanlevi
2016-06-30 20:48
Instead of spamming this channel by merely reminding us all about the new channel, I'll just say that I'm going to discuss the verbosity of the logging of the `membersrvc` process (https://github.com/hyperledger/fabric/issues/2085)...

jonathanlevi
2016-06-30 20:50
... here: # :wink:

simon
2016-07-01 12:56
there is a go implementation of the ethereum vm

simon
2016-07-01 12:56
should we look into optionally adding it as a system chaincode?

muralisr
2016-07-01 13:14
@simon I was thinking of a separate process implementation but go implementation would bring other optiosn

muralisr
2016-07-01 13:15
handy link ?


muralisr
2016-07-01 13:35
thanks much

thomas.leplus
2016-07-01 13:42
has joined #fabric-dev

ramesh
2016-07-01 14:36
Need help to analyze unit-test failures in Jenkins Z machine issue #2063


simon
2016-07-01 14:49
your docker doesn't seem to work?

ramesh
2016-07-01 14:57

ramesh
2016-07-01 15:14
It's firewall issue..

ramesh
2016-07-01 15:15
I deleted firewall rule from iptables which is rejecting..

ramesh
2016-07-01 15:15
all unit-tests are passed now.. :slightly_smiling_face:


gromeroar
2016-07-01 20:13
has joined #fabric-dev

sunsay00
2016-07-01 21:19
has joined #fabric-dev

simon
2016-07-05 13:29
how do i deal with objects that mutually require references to each other?

hgabor
2016-07-05 13:59
hi

hgabor
2016-07-05 13:59

simon
2016-07-06 11:09
hgabor: hi!

hgabor
2016-07-06 11:09
Hi

simon
2016-07-06 11:09
i'm looking at your pull request

hgabor
2016-07-06 11:10
Cool :-)

simon
2016-07-06 11:12
i guess this is a proposal/sketch?

simon
2016-07-06 11:13
it seems that in parallel i started working on the external consensus part: https://github.com/corecode/fabric/commits/separate-consensus

simon
2016-07-06 11:13
the only difference seems to be that I split the consensus API

simon
2016-07-06 11:14
into a `Deliver() returns stream` and a `Broadcast` rpc

hgabor
2016-07-06 11:15
Yes it is but we also have 3 older pr s, TX rejection events, noop chaincode and 'do not store failed txs'

simon
2016-07-06 11:15
we also should look into whether we want to stick to protobufs, or whether there are faster interfaces

simon
2016-07-06 11:15
oh i am totally in favor of those

simon
2016-07-06 11:15
i just can't commit

zsolt
2016-07-06 11:15
has joined #fabric-dev

simon
2016-07-06 11:16
cbf: you mentioned that GH doesn't have support for epics - wouldn't a checkbox list of sub-issues work?

hgabor
2016-07-06 11:17
For the sketch: we wanted to start a discussion on the new architecture and the different approaches :-)

cbf
2016-07-06 11:17
@simon: sure, you could maintain a list of links and some indication of whether they are complete, etc. but my point was that there is no formal handling of epics with GH issues.

hgabor
2016-07-06 11:18
I will have a look at your version @simon

simon
2016-07-06 11:18
cbf: i wonder whether checkmarked sub-issues can show their open/closed status

simon
2016-07-06 11:18
if so that would be quite close

cbf
2016-07-06 11:19
@simon: I am unaware of that capability to expose the status of an issue via a link.

cbf
2016-07-06 11:20
@hgabor: @tamas regarding the “sketch’ PR - would a feature branch be an effective means of moving this forward rapidly?

cbf
2016-07-06 11:21
and collaboratively

cbf
2016-07-06 11:22
@simon @jyellick would you be willing to collaborate on a feature branch approach to fleshing out the new consensus architecture?

cbf
2016-07-06 11:22
just trying to determine the most effective approach here

zsolt
2016-07-06 11:24
@cbf I think what is important, that there is some coordination about who does what. Right now there are multiple people developing the exact same thing, and it wastes a lot of effort. The feature branch will not help in this. Besides this, the feature branch can be useful for integration, but we also have a different problem here.

simon
2016-07-06 11:24
the consensus team has been doing that forever

simon
2016-07-06 11:24
we run our own feature branches in our forks

simon
2016-07-06 11:25
and work off of each other

cbf
2016-07-06 11:25
@simon private branches don’t count

simon
2016-07-06 11:25
because?

cbf
2016-07-06 11:25
because no one in the community can collaborate on those

simon
2016-07-06 11:25
everybody can

cbf
2016-07-06 11:25
if we are going to do this, we should do it as a function of hyperledger

simon
2016-07-06 11:25
ah yes

simon
2016-07-06 11:26
well, without easy committing

simon
2016-07-06 11:26
you'll never see efficient collaboration on the main repo

simon
2016-07-06 11:26
it takes days or months to get PRs in

zsolt
2016-07-06 11:27
@simon the problem with private branches, is that the others don’t know about them. For example in this case, you developed the same thing as we did, because there was no communication/coordination

simon
2016-07-06 11:27
yes

zsolt
2016-07-06 11:27
the same stands for us as well

cbf
2016-07-06 11:27
IMO, we should have similar rigor over feature branches as we do for the main code

simon
2016-07-06 11:27
that's not the problem of the private branch, but the problem of real bad communication infrastructure and culture in this project

cbf
2016-07-06 11:28
@simon: no doubt the communications and collaboration could use some improvement

cbf
2016-07-06 11:30
we could add maintainers for a feature branch - but I would want to ensure that the same criteria were being applied

cbf
2016-07-06 11:31
just because it is a feature branch shouldn’t diminish the need for comprehensive testing and effective documentation

cbf
2016-07-06 11:31
and we would definitely want multiple eyes reviewing code before it is merged

cbf
2016-07-06 11:32
in the context of a new feature, I also thin that at least one of the main project’s maintainers be actively involved

simon
2016-07-06 11:32
in what way?

cbf
2016-07-06 11:33
in reviewing at least

simon
2016-07-06 11:33
that doesn't scale

simon
2016-07-06 11:34
we already have a huge lag for PR merges

cbf
2016-07-06 11:34
otherwise when the feature is ready to be merged, there’ll be a gazillion lines of code to be reviewed - again, all at once

cbf
2016-07-06 11:34
and THAT does not scale

simon
2016-07-06 11:34
well that's why you have multiple people working together

cbf
2016-07-06 11:34
the maintainers can add more maintainers

simon
2016-07-06 11:34
well that has not happened at all

simon
2016-07-06 11:34
effectively there are 2.5 people who merge code

cbf
2016-07-06 11:48
yes, I am aware of that

jyellick
2016-07-06 13:54
@cbf I'm not opposed to a feature branch for this work, though to @simon's point, I'm not really sure what the benefit would be. If the merge process is the same, what is the advantage over working in master?

cbf
2016-07-06 15:00
@jyellick: well, it means master can continue unabated and without constant change - we can plan a more effective transition from just peer and membersrvc to one where we add another operational component into the mix.

cbf
2016-07-06 15:01
we could do the same with feature flags, I suppose

hgabor
2016-07-07 09:19
what should we do with our branch of next gen architecture?

hgabor
2016-07-07 09:19
we will check yours, that's ok

simon
2016-07-07 09:46
my branch is just for the separate consensus service

simon
2016-07-07 10:06
why do some parts of fabric use `grpclog`?

hgabor
2016-07-08 07:07
@simon I had a look at grpclog and - I guess you know this - it is the logging of grpc. so I agree that we should remove that from our code and use fabric logger instead

hgabor
2016-07-08 07:08
@cbf: Jenkins error 'protoc not found' is getting usual. Can I do anything to help fixing it? :slightly_smiling_face:

jay_guo
2016-07-08 12:35
has joined #fabric-dev

ramesh
2016-07-08 12:52
@hgabor: Please refer issue#2035

sheehan
2016-07-08 20:57
@simon: I think the protobuf ship has sailed and that’s what we’re using. https://google.github.io/flatbuffers/ seem interesting, but it would be a big change at this point

sheehan
2016-07-08 21:00
@simon: @cbf What about opening a PR for your branch and marking it WIP as was done at https://github.com/hyperledger/fabric/pull/2101 ? Then you (and others) can commit and people can see what you’re working on and make comments

cbf
2016-07-08 21:02
@sheehan: I agree that we should expose the various branches under development for the new consensus arch so that we can compare notes and hopefully converge on a single feature branch

sheehan
2016-07-08 21:20

cbf
2016-07-08 21:23
fine if one developer is doing all the work

cbf
2016-07-08 21:23
but not for larger problems that involve coordination of multiple threads of development

cbf
2016-07-08 21:24
something like the new consensus arch seems like something that more than one needs to work on, no?

sheehan
2016-07-08 21:24
not sure I understand. Multiple people can contribute to one PR.

cbf
2016-07-08 21:25
if they are working on a common branch, sure

cbf
2016-07-08 21:26
or am I missing something

simon
2016-07-08 21:38
cbf: the person who submitted the PR can pull contributions and merge them into their PR

sheehan
2016-07-08 21:41
yes, and sometimes I see people give others direct push access on their repository. Those would also show up in the PR, correct?

cbf
2016-07-08 22:41
well, I guess that’s my point… you need to have the development branch, wherever that is, available for others to push to (or submit PRs). This is why I think that feature branches hosted by Hyperledger Fabric and participating in CI make a bit more sense, though managing PRs to the branch needs some thought. I don’t know enough about Gerrit to know whether we can manage things more fine-grained.

buhrmi
2016-07-09 03:11
has joined #fabric-dev

zuowang
2016-07-11 07:36
Hi, If a Validator restart in the middle, will it sync its blockchain, worldstate and chaincode with other Validtors?

hgabor
2016-07-11 08:05
@zuowang: as far as I know yes

hgabor
2016-07-11 08:07
on master, I am unable to build protos (make protos). it fails with an error

hgabor
2016-07-11 08:12
bad import in /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/java/src/main/proto/chaincode.proto I think, I will fix it

hgabor
2016-07-11 08:19

zuowang
2016-07-11 08:24
Is it true that stub.GetState/DelState/PutState much faster than stub.GetRow/ReplaceRow/InsertRow ? At lease it gave such an impression when I looked into the code.

zuowang
2016-07-11 12:25
@hgabor: I killed a Validator then restarted it. It wouldn't sync chaincode with other Validators :sweat_smile:

simon
2016-07-11 12:29
sync?

hgabor
2016-07-11 12:31
hmm yes, chaincode is not on the ledger so it wont sync that. @simon please correct me if I am wrong

simon
2016-07-11 12:31
chaincode is part of the blockchain

simon
2016-07-11 12:31
i don't know what sync means

simon
2016-07-11 12:31
needs more detailed explanation

hgabor
2016-07-11 12:32
I guess it means synchronization of a node that lags behind the others

hgabor
2016-07-11 12:32
e.g. it is restarted

hgabor
2016-07-11 12:33
is system chaincode part of the ledger too? was't that removed from there? I am nearly sure that muralisr made a PR that removed system chaincodes from genesis block

zuowang
2016-07-11 12:49
I mean the restarted Validator should deploy the same chaincode with other Validators and sync transactions that lag behind

simon
2016-07-11 12:51
please explain the setup

zuowang
2016-07-11 12:54
I started 4 Validators, and deployed chaincode_example02. Then I invoked it several times. After that, I restarted one Validator. No chaincode deployed in that validator.

simon
2016-07-11 12:56
it was already deployed

simon
2016-07-11 12:57
do you mean no docker container was started?

zuowang
2016-07-11 12:57
But i haven't seen the container.

simon
2016-07-11 12:57
did you submit a new transaction?

simon
2016-07-11 12:58
@muralisr: maybe chaincodes should be launched when the peer restarts

muralisr
2016-07-11 13:00
@simon why ? sounds like they are not even there ?

simon
2016-07-11 13:00
why not?

simon
2016-07-11 13:00
it will have to be launched eventually

muralisr
2016-07-11 13:00
_No chaincode deployed in that validator._

simon
2016-07-11 13:00
wrong phrasing

simon
2016-07-11 13:00
what zuowang means is that no container is started

muralisr
2016-07-11 13:01
if it is there it should be started on invoke/query

simon
2016-07-11 13:01
yes

zuowang
2016-07-11 13:01
I submit a new transaction rightnow, and no container is started.

simon
2016-07-11 13:01
and i'm saying, why not lauch it when the peer starts

muralisr
2016-07-11 13:02
focusing on this problem :slightly_smiling_face: doesn’t make a diff

muralisr
2016-07-11 13:02
and that’s a different matter… I like the lazy start myself

simon
2016-07-11 13:03
why?

zuowang
2016-07-11 13:03
not sure. I an starting 4 validators in vagrant without memversvr.

muralisr
2016-07-11 13:03
@zuowang: what exactly are you seeing ?

zuowang
2016-07-11 13:04
fix a typo. not sure. I an starting 4 validators in vagrant without membersvr.

muralisr
2016-07-11 13:04
you submit a deploy

simon
2016-07-11 13:04
it will start a container when you submit a query to this node, or a invoke

muralisr
2016-07-11 13:04
but one validator does not have the deploy ?

zuowang
2016-07-11 13:05
I submited a invoke but the the container didn't start.

zuowang
2016-07-11 13:05
And query the chaincode will fail.

simon
2016-07-11 13:05
what's the error?

zuowang
2016-07-11 13:06
I don't think we need to deploy the chaincode again when one Validator restart from failure.

zuowang
2016-07-11 13:07
Error: Error querying chaincode: rpc error: code = 2 desc = "Error:Failed to launch chaincode spec(Could not get deployment transaction for 4c9eb45d4395ecf630296eddfe3a3cc49d8ee7a14a3fd0a9ce45ecb7a9420b1a6ab20f0e51198b70bcd904e16e874f72dde928ffe29fba429081217e925ff77f - LedgerError - ResourceNotFound: ledger: resource not found)"

zuowang
2016-07-11 13:10
@simon If it's a bug, could you help to reproduce in your machine?

simon
2016-07-11 13:10
no, sorry

simon
2016-07-11 13:10
i have a completely different branch running

simon
2016-07-11 13:10
this is something that is in @muralisr area

simon
2016-07-11 13:10
but i have not seen this problem yet

muralisr
2016-07-11 13:11
it basically says that the deployed transaction is not found in the ledger

zuowang
2016-07-11 13:13
sorry, I wil be offline rightnow

muralisr
2016-07-11 13:22
is it possible the invoke was done before the system “caught up” ? (apologize if I should have this info from above conversation…)

simon
2016-07-11 13:30
the setup was described as: 1. create 4 validator network, 2. deploy & invoke, 3. restart one validator, 4. submit query to restarted validator

simon
2016-07-11 14:41
why does chaincode still log such exorbitant amounts?

simon
2016-07-11 14:41
shouldn't that have been fixed long ago?

muralisr
2016-07-11 14:44
@simon, mostly in debug ?

simon
2016-07-11 14:44
no idea

simon
2016-07-11 14:44
docker uses 30% cpu

simon
2016-07-11 14:44
and docker logs is super busy

muralisr
2016-07-11 14:46
ok. i was going to do some runs without logs. I always have to go back and figure out how to turn off logs.

muralisr
2016-07-11 14:49
going to get started on this this week

simon
2016-07-11 14:59
i think the logs should be off except for development mode

simon
2016-07-11 14:59
and if there is something important to log, it should be aggregated into the main log

jonathanlevi
2016-07-11 16:16
---

jonathanlevi
2016-07-11 16:16
Good morning!

jonathanlevi
2016-07-11 16:16
Do we have any `soft` or `hard` policy regarding unused code?

jonathanlevi
2016-07-11 16:17
I found some more code that is not being used yet, and I suggest to remove it (until it is used)... but I wonder if it's my opinion/do others subscribe to this point of view....or otherwise?

cbf
2016-07-11 16:27
personally, I don’t like dead code

cbf
2016-07-11 16:27
if the code is being added for a disabled feature, that’s another thing entirely

cbf
2016-07-11 16:27
however, code that is added without a clear path to its use seems silly to me

cbf
2016-07-11 16:28
we can always recover later if someone comes up with a need

jonathanlevi
2016-07-11 16:35
Yes, I agree. Especially in `git` where nothing's really deleted.

simon
2016-07-11 16:36
what specifically?

jonathanlevi
2016-07-11 16:37
Also, IMO it's much easier to review code, when one sees how it is being used/check that tests test/replicate an actual use-case, etc.

jonathanlevi
2016-07-11 16:38
@simon 2111, for example


jonathanlevi
2016-07-11 16:40
(that underlying code needs some work, IMO)

jonathanlevi
2016-07-11 16:40
And it can be probably (re)introduced as part of the usage

simon
2016-07-11 16:41
i guess

jonathanlevi
2016-07-11 16:44
@simon: Is this a yes/no or a maybe? :wink:

simon
2016-07-11 16:46
it's an i don't care enough to have an opinion

simon
2016-07-11 16:46
there are many more things that are just awful in this codebase

jonathanlevi
2016-07-11 16:53
I completely agree with you. Trying to (sometimes/more often) change what bothers me, at least...

cbf
2016-07-11 17:29
@simon all the more reason to omit code that isn’t used

jeffgarratt
2016-07-11 18:09
@cbf: @jonathanlevi it is fairly straight forward to create a full coverage report of the code which should also indicate dead paths (or missing tests :slightly_smiling_face: )

jonathanlevi
2016-07-11 19:01
@jeffgarratt: Absolutely. Even more so for a struct that is never called (yet)

zuowang
2016-07-12 00:30
@simon @muralisr : I actually have reported the high docker cpu usage issue and pushed a PR half a month ago. But was suggested to close. https://github.com/hyperledger/fabric/pull/2024

simon
2016-07-12 09:17
zuowang: i see

simon
2016-07-12 09:19
i think chaincode shouldn't log at all by default

simon
2016-07-12 09:19
it is not going anywhere where the log can be captured

simon
2016-07-12 09:19
easily

simon
2016-07-12 09:19
i'm always in favor of simpler code, rather than more complicated code

hgabor
2016-07-12 10:50
what is a car file? there is one in core/chaincode/platforms/car/test

simon
2016-07-12 10:57
chaincode archive, i think

hgabor
2016-07-12 11:01
and how can one create such an archive?

simon
2016-07-12 11:06
i have no idea - ghaskins worked on this

ghaskins
2016-07-12 11:07

ghaskins
2016-07-12 11:07
"chaintool package" specifically would be used to create a .car

hgabor
2016-07-12 11:09
so in order to replace that car file I mentioned before, I have to run this, right?

hgabor
2016-07-12 11:10
I want to create a new car file because I modified the example chaincode the car file was created from

ghaskins
2016-07-12 11:11
Sounds like that is the case

hgabor
2016-07-12 11:11
thanks

ghaskins
2016-07-12 11:12
Note that vagrant comes prepackaged with chaintool already in the path

ghaskins
2016-07-12 11:12
It's an older version, but that shouldn't matter for package operation

ghaskins
2016-07-12 11:14
Also, let me know what the mod was so I can figure out if I should merge it with the examples in the chaintool repo

hgabor
2016-07-12 11:15
I am trying to create a PR where we use TxID instead of UUID. TxID is created using all the parameters of a chaincode (arguments, args) by calling SHA256

hgabor
2016-07-12 11:16
I have replaced the current type of args ([]string) with [][]byte

hgabor
2016-07-12 11:16
this made me modify the chaincode examples

simon
2016-07-12 11:17
hgabor: but what if you invoke the same chaincode twice with the same args?

simon
2016-07-12 11:18
won't you have the same ID then?

simon
2016-07-12 11:18
and why [][]byte?

simon
2016-07-12 11:19
and why is ghaskins awake

ghaskins
2016-07-12 11:19
I would share @simon's concern. Also don't understand why you would need to change the parameter types to generate a hash

ghaskins
2016-07-12 11:20
Heh, not only should I not be awake, I am technically still on holiday until tomorrow ;)

tamas
2016-07-12 11:24
@ghaskins: why would we have strings? Strings are natural for command line but not for an rpc interface.

hgabor
2016-07-12 11:25
[][]byte can be interpreted in any way - it depends on the chaincode so it is more general. it is easy to generate a hash using bytes. if we used a string we would need some method to create bytes from it. but this is not trivial, how to do it? UTF8? some other decoding?

ghaskins
2016-07-12 11:26
@tamas: I don't disagree with that. Chaintool does exactly this by encoding protobuf objects with the string

tamas
2016-07-12 11:29
@simon if it was permissible to call chaincode with same args then it would be open to trivial replay attack

simon
2016-07-12 11:29
the chaincode call contract is different from the transaction that wraps the arguments

simon
2016-07-12 11:30
a transaction contains a timestamp, and crypto fields

simon
2016-07-12 11:30
nonce, signature, etc.

simon
2016-07-12 11:31
tamas: however, replay attack protection is essentially non-existent in fabric at the moment

ghaskins
2016-07-12 11:31
@hgabor: that sounds more like a golang specific challenge of dealing with string types than a core requirement for hashing

simon
2016-07-12 11:31
hgabor: then the arguments should be []byte?

ghaskins
2016-07-12 11:31
But that said, I see both you and @tamas points

simon
2016-07-12 11:32
[]byte("string")

simon
2016-07-12 11:32
gives you the bytes to a string

simon
2016-07-12 11:33
i think we should either do `args []byte` and the chaincode does the unmarshalling and interpretation itself

tamas
2016-07-12 11:33
@simon I can not see the difference call contract vs. transaction. I assume that it is the job of chaincode to decide if transaction is valid.

hgabor
2016-07-12 11:34
@simon yes and this way the client can easily generate the hash/ID of a TX. but if we used []bytes("string") then the client would have to convert all the arguments he wants to send to fabric to UTF8 byte arrays and calculate the SHA256 from that. and IMO this is ugly. :slightly_smiling_face: but a byte array... for a chain code it can mean anything. e.g. one can encode chaincode specific information into that byte array. this is more general.

simon
2016-07-12 11:34
or we enforce an array of strings, or (my preference) a validly parsing object (JSON?)

simon
2016-07-12 11:35
tamas: let's take a simple counter chaincode. it has one function, "increment". how would that chaincode perform replay protection?

hgabor
2016-07-12 11:36
@simon IMO args [] byte is the same as args [][]byte. one only have to concatenate those bytes and add field delimiters. :slightly_smiling_face:

ghaskins
2016-07-12 11:36
I guess what I don't understand is why are you even looking at payload fields

simon
2016-07-12 11:36
hgabor: so it isn't the same

hgabor
2016-07-12 11:37
@simon so you prefer []byte ?

simon
2016-07-12 11:37
with v2, the mvcc/readset will automatically prevent replay attacks though

ghaskins
2016-07-12 11:38
Back to bed for me. I'll be fully online tomorrow. Cheers

simon
2016-07-12 11:38
hgabor: a pure `[]byte` is elegant, on one side of the spectrum

simon
2016-07-12 11:39
and it allows the flexibility of chaincodes to use any kind of serialization format

hgabor
2016-07-12 11:39
@simon I like the idea of []byte

simon
2016-07-12 11:39
the disadvantage is that you cannot generically process/analyze chaincode arguments across chaincodes.

tamas
2016-07-12 11:40
simon: "increment" is flawed by design. Should not have transactions that are valid if replayed with chaincode

simon
2016-07-12 11:40
tamas: unless you rely on the fabric to prevent replay

simon
2016-07-12 11:40
i.e. remove the burden of replay protection from the individual chaincode

tamas
2016-07-12 11:40
@simon I do not want to rely on fabric n any means other than orchestrating functions that are in my control\

simon
2016-07-12 11:42
i think this is a most fundamental issue and should be addressed by the technical discussion mailing list

simon
2016-07-12 11:43
i just know that writing chaincode is difficult

tamas
2016-07-12 11:43
transactions, blocks and their consensus order have to be audit-able without assuming a protection by fabric

simon
2016-07-12 11:43
and people will find all kinds of ways on how to fail to check for replays :slightly_smiling_face:

simon
2016-07-12 11:44
how does ethereum prevent against replays?

simon
2016-07-12 11:44
does the individual smart contract check for replays?

tamas
2016-07-12 11:44
ask me how Bitcoin does. I do not consider Ethereum as design target

simon
2016-07-12 11:45
i know how bitcoin does it. but fabric tries to be more general than UTXO

simon
2016-07-12 11:46
see, for me it is the best news if i don't have to care about mistakenly introducing duplication in consensus

simon
2016-07-12 11:46
because that complicates our code

tamas
2016-07-12 11:47
UTXO is a specific concept for coins. It has the side effect of replay protection. I think every serious chain code will have to think about how it avoids replay. Having previous transaction reference (similar to utxo) is one but not the only way.

tamas
2016-07-12 11:48
I can not think of a serious system that allows replay.

simon
2016-07-12 11:49
i understand your point

simon
2016-07-12 11:49
but this needs to be discussed on the mailing list. i have no authority in this area

tamas
2016-07-12 11:49
me not too, just discussing

simon
2016-07-12 11:49
my expectation was that the fabric would prevent replay

simon
2016-07-12 11:50
and an audit log later can prove that indeed no transaction was replayed

tamas
2016-07-12 11:50
if replay was prevented by fabric then it was some kind of global index, which is expensive

tamas
2016-07-12 11:50
if chaincode can guarantee uniqueness cheaper we are better off

simon
2016-07-12 11:50
yes, i agree

simon
2016-07-12 11:51
domain knowledge can simplify things

tamas
2016-07-12 11:51
exactly

simon
2016-07-12 11:53
however, if implemented well, a generic replay protection will benefit all chaincodes

tamas
2016-07-12 11:54
We need a blockchain that processes thousands of tx per second. Can you think of a global generic check of uniqueness that is cheap after years?

simon
2016-07-12 11:54
i believe the security folks had in mind some limited time valid certificates

tamas
2016-07-12 11:55
that puts trust to a CA, not sure I want to do that if not needed

simon
2016-07-12 11:55
then you only have to maintain some sort of database (per chaincode) for N * these periods

simon
2016-07-12 11:58
tamas: i think these (low-level?) issues need to be addressed by the technical list

simon
2016-07-12 11:58
and i don't think this is happening properly

simon
2016-07-12 11:59
most things seem to be spur of the moment decisions

tamas
2016-07-12 12:22
ok I write a mail to the list

simon
2016-07-12 12:23
thanks!

hgabor
2016-07-12 12:55
does anybody know core/chaincode/exectransaction_test.go?

yingfeng
2016-07-13 02:14
it seems a redesign of fabric according to the proposals: https://github.com/hyperledger/fabric/wiki/Fabric-Next what's the plan for the first production ready release?

sheehan
2016-07-13 02:42
@hgabor: I believe @muralisr wrote that test

sheehan
2016-07-13 02:43

sheehan
2016-07-13 02:46
If you can’t make it, I think the roadmap will likely be posted next week

grapebaba
2016-07-13 10:00
in doc anyone can re trigger travis build, but actually i cannot, always get a error. anyone know?

sheehan
2016-07-14 00:39
I think it’s limited. @ramesh would know

ry
2016-07-14 00:45
grapebaba: which PR?

ramesh
2016-07-14 01:05
@grapebaba: user having write access to the repo can re-trigger travis builds.. Otherwise, send a request through PR comment or Slack to maintainers to re-run the travis build.

grapebaba
2016-07-14 01:07
@ry: @sheehan already triggered. thanks @ramesh

ramesh
2016-07-14 01:07
ok

lbonniot
2016-07-14 07:42
has joined #fabric-dev

simon
2016-07-14 09:18
is grpc considered a forever stable serialization format?

simon
2016-07-14 09:18
because if not, we shouldn't use it to create bytestreams we hash + sign

hgabor
2016-07-14 09:25
I don't think that the byte / wire format it uses would be forever stable

hgabor
2016-07-14 09:25
and fixed (the order of fields etc)

hgabor
2016-07-14 09:28
we ran into some problem with a behave test: chaincode example02 with 4 peers, stop and start alternates, reverse; the test wants 977 on A's account but we have 993. it seems that a query is executed before an invocation despite they are present in the opposite order in the behave test markup file

hgabor
2016-07-14 09:28
what can cause this?

simon
2016-07-14 09:33
all these tests are fragile

simon
2016-07-14 09:33
because they're dealing with a distributed system

zsolt
2016-07-14 09:45
@simon I don’t think its fragility in this case. The ‘when’ of the invocation is BEFORE the ‘when’ of the query in this scenario, however in the docker log, the first invoke happens 10 seconds AFTER the query. It seems, that behave will not keep the ordering of these ‘when’ sentences. If we put a 'wait “20” seconds’ between these two, then the test passes. I am not familiar with this behave framework, but I hope there is someone here who does, and can explain this behaviour

simon
2016-07-14 09:47
heh

simon
2016-07-14 09:47
that seems weird

zsolt
2016-07-14 09:48
@simon I agree :slightly_smiling_face:

zsolt
2016-07-14 09:48
08:54:09.317 [shim] DEBU : [ca978112]Query completed. Sending QUERY_COMPLETED Query Response:{"Name":"a","Amount":"993"} 08:54:18.750 [shim] DEBU : [ca5ba87c]Received message TRANSACTION from shim 08:54:18.750 [shim] DEBU : [ca5ba87c]Handling ChaincodeMessage of type: TRANSACTION(state:ready) 08:54:18.750 [shim] DEBU : [ca5ba87c]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:transaction) 08:54:18.750 [shim] DEBU : [ca5ba87c]Sending GET_STATE 08:54:18.751 [shim] DEBU : [ca5ba87c]Received message RESPONSE from shim 08:54:18.751 [shim] DEBU : [ca5ba87c]Handling ChaincodeMessage of type: RESPONSE(state:transaction) 08:54:18.751 [shim] DEBU : [ca5ba87c]before send 08:54:18.751 [shim] DEBU : [ca5ba87c]after send 08:54:18.751 [shim] DEBU : [ca5ba87c]Received RESPONSE, communicated (state:transaction) 08:54:18.751 [shim] DEBU : [ca5ba87c]GetState received payload RESPONSE 08:54:18.751 [shim] DEBU : [ca5ba87c]Sending GET_STATE 08:54:18.752 [shim] DEBU : [ca5ba87c]Received message RESPONSE from shim 08:54:18.753 [shim] DEBU : [ca5ba87c]Handling ChaincodeMessage of type: RESPONSE(state:transaction) Aval = 992, Bval = 8

zsolt
2016-07-14 09:49
this is the log, with the query and the first invoke

satheesh
2016-07-15 15:20
Has anyone got TLS communication between fabric and chaincode working ?

sheehan
2016-07-15 16:48
@simon: "is grpc considered a forever stable serialization format?” I’ve asked that same question before. I looked through their documentation in the past and never found anything that said it was. I had this conversation with @jeffgarratt and I feel like maybe he said something to convince me, but now I forget his answer and don’t trust that we use it for generating bytes to hash + sign.

muralisr
2016-07-15 21:22
@satheesh: I believe @mrshah did have it working

mrshah
2016-07-15 21:23
yep, we have TLS working between fabric & chaincode

leo
2016-07-16 04:47
has joined #fabric-dev

satheesh
2016-07-16 08:03
@muralisr: thanks. I will get in touch with @mrshah after this weekend

pniang
2016-07-16 16:26
has joined #fabric-dev

simon
2016-07-19 10:31
anybody around?

deeflorian
2016-07-19 14:15
Does anyone know why a single invoke of a CC results in 5 messages to the docker container (using the example2 CC)? The first one has the type `Transaction` which kind of makes sense, but the next 4 are of type `Response` -- seems kind of unintuitive for me as the peer's the one supposed to be waiting for a response.

simon
2016-07-19 14:20
which container?

simon
2016-07-19 14:21
the chaincode container?

deeflorian
2016-07-19 14:22
regarding grpc, the docs mention "Wire format ordering and map iteration ordering of map values is undefined, so you cannot rely on your map items being in a particular order. " -- it's related to maps, but the docs really doesn't seem to mention anything more specific...

deeflorian
2016-07-19 14:22
yepp

deeflorian
2016-07-19 14:24
(found this when I looked into the `serialSend` function in core/chaincode/handler.go)

muralisr
2016-07-19 14:28
@deeflorian: access to ledger state (as in GetState/PutState) results in messages between chaincode and peer

s.matthew.english
2016-07-19 14:28
has joined #fabric-dev

muralisr
2016-07-19 14:28
that’s probably what you saw

deeflorian
2016-07-19 14:32
@muralisr: thanks :slightly_smiling_face:

s.matthew.english
2016-07-19 14:39
so I was trying the command: ./peer chaincode deploy -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}' it said "./peer is a directory" and didn't work so I pointed it to "/build/bin/peer" but I got Error: Error building chaincode: Error trying to connect to local peer: grpc: timed out trying to connect

muralisr
2016-07-19 14:42
@s.matthew.english: I think you are in fabric/ directory

muralisr
2016-07-19 14:42
cd peer

muralisr
2016-07-19 14:43
and try the command

s.matthew.english
2016-07-19 14:43
ah

s.matthew.english
2016-07-19 14:43
ok

s.matthew.english
2016-07-19 14:43
wait

s.matthew.english
2016-07-19 14:43
where is peer

s.matthew.english
2016-07-19 14:43
in the /fabric director

s.matthew.english
2016-07-19 14:43
peer is a directory that lives there

s.matthew.english
2016-07-19 14:43
not the peer file in bin

muralisr
2016-07-19 14:44
yes

muralisr
2016-07-19 14:44
I’d “cd peer"

muralisr
2016-07-19 14:44
go build

muralisr
2016-07-19 14:44
./peer chaincode deploy -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'

muralisr
2016-07-19 14:44
but beofre tht

s.matthew.english
2016-07-19 14:45
you mean

s.matthew.english
2016-07-19 14:45
issue 'build' as a command

s.matthew.english
2016-07-19 14:45
in the peer directory

muralisr
2016-07-19 14:45
in another vagrant window, start the peer with “./peer node start"

muralisr
2016-07-19 14:45
I meant literally “go build” to build the peer executable

s.matthew.english
2016-07-19 14:46
ah ok

s.matthew.english
2016-07-19 14:47
something happened

s.matthew.english
2016-07-19 14:47
I got this

s.matthew.english
2016-07-19 14:47
a5389f7dfb9efae379900a41db1503fea2199fe400272b61ac5fe7bd0c6b97cf10ce3aa8dd00cd7626ce02f18accc7e5f2059dae6eb0786838042958352b89fb

s.matthew.english
2016-07-19 14:48
:confused: what does it mean?

s.matthew.english
2016-07-19 14:59
in http://localhost:5000/ I got {"Error":"Openchain endpoint not found."}

jeffgarratt
2016-07-19 16:01
@s.matthew.english: try http://localhost:5000/chain

s.matthew.english
2016-07-19 20:01
@jeffgarratt: cool- that works--> I see this: {"height":4,"currentBlockHash":"vfTQvQL3dQJ3X6oD+9/oBammpS3tCzeq9WYmM3oPCh5HMVUlUbok/ij8u/NEq+zRmHJrM22G4t132M35KfivGA==","previousBlockHash":"YVtf0I9hWRY1sqayQ/OmaiA59cPsL9BS/lA+6aE1rsAiIKFKoiPIpJeMnGrPgtDj/LzJLGNlNvhQy++G4bCviA=="} but- what does it mean?

jeffgarratt
2016-07-19 20:19
that is the chain information, height is block height, etc.

s.matthew.english
2016-07-20 07:48
@jeffgarratt aha- I see. I guess it's based on the parameters I passed when I executed the command, i.e. '{"Function":"init", "Args": ["a","100", "b", "200"]}' or is it left over from my previous attempts? the example I was using was ./peer chaincode deploy -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}' do you know what this is doing at a high level? maybe... assigns 100 widgets to 'a' and 200 to 'b'? records that information on the ledger through a hash?

ikruiper
2016-07-20 11:05
has joined #fabric-dev

liewsc
2016-07-20 15:12
has joined #fabric-dev

rseeger
2016-07-21 17:38
has joined #fabric-dev

dulcinea
2016-07-22 00:01
has joined #fabric-dev

bgorman
2016-07-22 02:44
has joined #fabric-dev

bgorman
2016-07-22 02:45
does anyone here understand what goes into the payload of http://localhost:5000/transactions/<chaincodeID> ? It seems to be about 3MB for chaincode_example02 but I haven't figured out what it actually is yet

jcarrivick
2016-07-22 02:46
has joined #fabric-dev

bgorman
2016-07-22 02:49
this is for the Transaction_CHAINCODE_DEPLOY messages

ghaskins
2016-07-22 03:01
@bgorman: i do

bgorman
2016-07-22 03:02
hey, great, I've dug down to the level of a CodePackage []byte so far :slightly_smiling_face:

ghaskins
2016-07-22 03:02
its basically your chaincode plus your GOPATH, tarred up

bgorman
2016-07-22 03:02
so it is the ELF binary in there?

ghaskins
2016-07-22 03:02
no, not at that level

bgorman
2016-07-22 03:02
a zip of the source code then?

ghaskins
2016-07-22 03:02
the ELF is reconstructed on each VP

ghaskins
2016-07-22 03:02
yes, but tar not zip

bgorman
2016-07-22 03:02
ah ok

bgorman
2016-07-22 03:03
I didn't try comparing it to a tar

ghaskins
2016-07-22 03:03
in case you are curious, the logic that is building that payload is here….


ghaskins
2016-07-22 03:04
thats if you are using the NVP/chaincode-client/REST mechanism

ghaskins
2016-07-22 03:04
if you are using the SDK, it has its own packager which was modeled on the code referenced above

ghaskins
2016-07-22 03:05
(i am not familiar with the SDK internals, so I cant point you to a line number, but I know it is a rough analog to that)


ghaskins
2016-07-22 03:06
is what is injecting the instruction that will ultimately cause the binary to be reconstructed around the network

jcarrivick
2016-07-22 03:06
@ghaskins: ahhh so this is where the docker commands get built to build the chaincode environment too!

ghaskins
2016-07-22 03:06
yep

ghaskins
2016-07-22 03:07
the tarball is actually a tarball + Dockerfile, suitable for passing to the docker build API

jcarrivick
2016-07-22 03:07
I was just adding some logging for the docker build commands and was seeing this exact output!

ghaskins
2016-07-22 03:07
yep

ghaskins
2016-07-22 03:07
to be clear, this _is_ the chaincode env builder

ghaskins
2016-07-22 03:08
the other docker environments are built differently

ghaskins
2016-07-22 03:10
the pattern repeats for the other platforms we currently support: https://github.com/hyperledger/fabric/tree/master/core/chaincode/platforms

ghaskins
2016-07-22 03:11
though, actually, the CAR implementation needs to be updated

ghaskins
2016-07-22 03:11
(the CAR file already is its own archive, so it was a mistake on my part to repackage it into a tar here)

jcarrivick
2016-07-22 03:13
thanks @ghaskins! another question if I may, what is CAR?

ghaskins
2016-07-22 03:13
chaincode archive, output of chaintool (https://github.com/hyperledger/fabric-chaintool)

ghaskins
2016-07-22 03:14
(I really need to add a comment in there, this gets asked often)

jcarrivick
2016-07-22 03:15
oh cool! I'll have to do some reading up on all that then :slightly_smiling_face:

bgorman
2016-07-22 03:17
@ghaskins that package.go you linked before actually excludes the chaincode path from the tar. Does it actually write the source into the tar file as part of hash.go? https://github.com/hyperledger/fabric/blob/master/core/chaincode/platforms/golang/hash.go#L61

ghaskins
2016-07-22 03:17
i no longer recall the details there, let me look again

ghaskins
2016-07-22 03:21
@bgorman: that is correct, its a little obtuse

ghaskins
2016-07-22 03:21
that code should be cleaned up

ghaskins
2016-07-22 03:22
I think if you follow the logic through, this function ends up packaging up the chaincode: https://github.com/hyperledger/fabric/blob/master/core/chaincode/platforms/golang/hash.go#L61

bgorman
2016-07-22 03:22
yeah, I think it may be line 91 that writes the files to the tar

ghaskins
2016-07-22 03:22
opps, sorry, thats the same link you provided

bgorman
2016-07-22 03:22
the function does a little more than it says on the tin :wink:

ghaskins
2016-07-22 03:23
yeah, it needs to be refactored for sure

ghaskins
2016-07-22 03:23
and yes, I agree about L91

bgorman
2016-07-22 03:23
ok, thanks, I think I have it straight in my head now :slightly_smiling_face:

ghaskins
2016-07-22 03:23
the confusing layout is partly my fault

bgorman
2016-07-22 03:24
@jcarrivick: so one peer needs the code, the others get a tarball of the source through the chain and transaction

ghaskins
2016-07-22 03:24
it used to be one .go file that did all the tarball/docker stuff, and I had broken it out into the platforms mechanism that we have today

ghaskins
2016-07-22 03:24
but the refactoring of the golang platform wasnt as clean as it could have been, needs to be teased out more

ghaskins
2016-07-22 03:25
@bgorman: that is _mostly_ correct

bgorman
2016-07-22 03:25
@ghaskins: so is there support for Java chaincodes too?

ghaskins
2016-07-22 03:25
yes, I believe that was merged though I havent worked with it myself

ghaskins
2016-07-22 03:26
your assessment about one peer building the tarball and the other peers consuming the tarball is correct….

ghaskins
2016-07-22 03:26
what should be pointed out is that this was intended to be a trusted-NVP function, not just any peer

ghaskins
2016-07-22 03:26
IOW, the thing that is building your tarball, the REST API, etc, are actually considered part of your clients stack

ghaskins
2016-07-22 03:27
once you understand that detail, some of the other things that are happening start to make more sense

bgorman
2016-07-22 03:27
ok, thanks. I haven't played with non-validating peers yet. Just using the 4 validating ones.

ghaskins
2016-07-22 03:28
yeah, thats fine…its just a mental delineation for the purposes of this conversation

ghaskins
2016-07-22 03:28
just, if you start to look at some of the details, like: the files have to be local to the (N)VP (for non http anyway), the rest API takes fairly unsound looking tokens, etc

ghaskins
2016-07-22 03:29
its because the peer/rest-client assumes the other side of the link is within your trust domain

ghaskins
2016-07-22 03:29
so, you can use any arbitrary VP in this capacity and it will technically work

ghaskins
2016-07-22 03:30
it just might not be a good idea for production if you actually need security :wink:

ghaskins
2016-07-22 03:31
for production, you’d want to either use the SDK which incorporates all the NVP functions into your app, or stand up an NVP in your own environment

jcarrivick
2016-07-22 03:31
@ghaskins: So if I understand this correctly, a client could bring up a peer with the code they want to deploy, deploy it to that peer, and the rest of the network gets it via the blockchain

jcarrivick
2016-07-22 03:32
but the initial peer would have to have a local copy of it

ghaskins
2016-07-22 03:33
thats basically true, though note that I think we are migrating to the SDK type model and deprecating the current client+NVP model

ghaskins
2016-07-22 03:33
IIUC

ghaskins
2016-07-22 03:33
just right now, both still exist

ghaskins
2016-07-22 03:33
personally, ive already moved over to the SDK for my development

jcarrivick
2016-07-22 03:33
so basically,... we should start learning how to use the SDK

ghaskins
2016-07-22 03:33
that would be my advise

ghaskins
2016-07-22 03:33
advice

jcarrivick
2016-07-22 03:34
sweet, I know what I'm doing for the rest of today then :slightly_smiling_face:

ghaskins
2016-07-22 03:34
ive successfully used it with both pure nodejs as well as cljs

ghaskins
2016-07-22 03:34
it works really well

ghaskins
2016-07-22 03:35
i recommend just working with whats in NPM rather than trying to build it youself

ghaskins
2016-07-22 03:35
depending on your proclivity for getting your hands dirty, i suppose

jcarrivick
2016-07-22 03:36
great :slightly_smiling_face: I'll see how I go then :slightly_smiling_face:

jcarrivick
2016-07-22 03:36
Thanks for all the help :slightly_smiling_face:

ghaskins
2016-07-22 03:37
any time

ghaskins
2016-07-22 03:37
FWIW, I have a few examples of using the SDK in the chaintool repo

ghaskins
2016-07-22 03:37
they are chaintool specific, but it wouldnt be hard to convert them to standard protocol clients

ghaskins
2016-07-22 03:38
for instance, here is a cheesy nodejs version


ghaskins
2016-07-22 03:38
not fully featured, just hacks a few requests together

ghaskins
2016-07-22 03:38
opps, im sorry

ghaskins
2016-07-22 03:38
that is a REST client, not SDK

ghaskins
2016-07-22 03:38
i think the only SDK client I have published is cljs


jcarrivick
2016-07-22 03:39
great, thanks :slightly_smiling_face: I'll be sure to take a look

ghaskins
2016-07-22 03:39
but still, the doc is pretty good

pranob
2016-07-22 09:52
has joined #fabric-dev

ray
2016-07-22 15:43
has joined #fabric-dev

cbf
2016-07-22 22:09
: I’m about to push a PR to reassign port assignments as follows:

cbf
2016-07-22 22:09
port assignment changes 7050 REST 7051 peer gRPC 7052 peer CLI 7053 peer events 7054 eCAP 7055 eCAA 7056 tCAP 7057 tCAA 7058 tlsCAP 7059 tlsCAA

cbf
2016-07-22 22:10
Note that the membersrvcs ports seem to be mostly unused thus far

sheehan
2016-07-22 22:14
I can test the PR in OSX to ensure no conflicting ports. If anyone on Windows has time to check it would be helpful

cbf
2016-07-22 22:15
re-running behave because there was what I think was a timing issue in last pass

arnaud
2016-07-22 22:22
I'm happy to test on Windows

cbf
2016-07-22 22:29
ok, pushed commit


arnaud
2016-07-22 23:40
I'm testing it on Windows

simon
2016-07-25 10:13
can't we just combine all GRPC ports and all http ports?

simon
2016-07-25 10:13
then we have 2 ports

huxd
2016-07-25 10:48
has joined #fabric-dev

cbf
2016-07-25 19:52
works for me… we do have an abundance of ports which isn’t so cool

kostas
2016-07-25 20:31
How many old issues will @cbf close today? The over/under is at 80, taking bets.

cbf
2016-07-25 20:39
lol

muralisr
2016-07-25 22:10
@simon @cbf one of the “con” for common grpc port - we have to use the same SSL creds for all (e.g., 30303 for both peer-peer and peer-chaincode GRPC communication - which is what we have today btw)

jonathanlevi
2016-07-25 23:57
@kostas: what's the spread? And who's taking bets? (Please let's not set up a DAO for this too, in which case, I'm not gambling!)

simon
2016-07-26 08:14
muralisr: what's the problem with using the same tls creds?

simon
2016-07-26 08:15
muralisr: i think the chaincode communication port can be entirely ephemeral. i'd go so far and use an fd passed to the docker process, instead of opening a tcp socket.

naruhito.t
2016-07-26 14:33
has joined #fabric-dev


gongsu
2016-07-27 01:58
Question on chaincode API GetCallerCertificate. Does it get the TCert or the ECert? From the doc of ReadCertAttribute, etc., it appears that the answer is TCert? If so, is there any reason why there is no corresponding API for the ECert? Thanks.

cbf
2016-07-27 12:53
Migrating PRs that have been submitted (or are in-progress) to Gerrit involves creating a patch set that you can apply to your new Gerrit clone (see previous email). As a reminder our Gerrit is here https://gerrit.hyperledger.org/r/#/admin/projects/fabric Step 1 rebase your PR commits in your local clone of your hyperledger/fabric fork a. git checkout master b. git fetch origin master c. git checkout <your PR branch> d. git rebase -i origin/master e. <optionally, resolve any merge conflicts> f. git push -f Step 2 generate a patch for your PR from your hyperledger-fabric fork a. open your GH fork repo page b. change to your PR's branch c. right below the branch selector you should see "This branch is N commits ahead of hyperledger:master d. on the right-hand side of that bar, click on the 'Compare' glyph. this will open a page comparing your changes with the origin and should have a URL like this example: https://github.com/hyperledger/fabric/compare/master...christo4ferris:issue-2277 e. append '.patch' to that URL in your browser window and you will be redirected to a raw patchset for your changes. COPY this URL, which should look something like this: https://github.com/hyperledger/fabric/compare/master...christo4ferris:issue-2277.patch f. open a terminal window and copy this patchset to your local machine e.g. 'curl -XGET https://github.com/hyperledger/fabric/compare/master...christo4ferris:issue-2277.patch -o 2277.patch' Step 3 apply the patch for your PR to your Gerrit clone a. cd <your gerrit clone dir> b. git checkout -b <your PR branch> c. git apply <path to patchset>/<patchset filename> d. git add * e. git commit -s f. add commit message, etc g. git push origin HEAD:refs/for/master Step 4 visit Gerrit to check that your commit was pushed and created a review. Please let me know if you have any difficulties with transferring your PRs. I'll be on slack all day.

simon
2016-07-27 12:54
cbf: the hyperledger code is empty

cbf
2016-07-27 12:55
in gerrit?

simon
2016-07-27 12:55
yes

simon
2016-07-27 12:55
i guess we're not starting from 0, because you talk about PRs

cbf
2016-07-27 12:56
I just cloned and it’s all there


ghaskins
2016-07-27 12:57
@simon: you want “fabric"

ghaskins
2016-07-27 12:57
it has the same structure as GH

simon
2016-07-27 12:57
aha

simon
2016-07-27 12:57
what is fabric-api?


simon
2016-07-27 12:57
wait, we didn't retain the history?

ghaskins
2016-07-27 12:57
same as it was in GH, I would imagine: DAH contribution

simon
2016-07-27 12:57
why?

ghaskins
2016-07-27 12:58
this is a good point, why didnt we import history?


cbf
2016-07-27 12:58
@simon ^^

cbf
2016-07-27 12:58
@ghaskins: I explained in my note… basically LF insists on a single commit to start to ensure IP hygiene

ghaskins
2016-07-27 12:59
ah, ok, sorry

simon
2016-07-27 12:59
what's the difference?

cbf
2016-07-27 12:59
we will keep the GH repos as archived for posterity

simon
2016-07-27 12:59
that's just sloppy

simon
2016-07-27 12:59
super duper sloppy

simon
2016-07-27 13:00
now everybody needs to graft the github repo to use git blame

cbf
2016-07-27 13:00
how so

simon
2016-07-27 13:00
because the whole idea about git is that you don't have to do this

ghaskins
2016-07-27 13:00
I dont know if I would go so far as to agree that its “sloppy” but I do agree this can cause some problems

cbf
2016-07-27 13:01
yes, well, awkward but this is what we were required to do… if we started it would have been that way as well.

ghaskins
2016-07-27 13:01
i already ran into some issues trying to figure out why something was the way it was back in april when the OBC->HL migration occured

simon
2016-07-27 13:02
yea the renaming already made it difficult

ghaskins
2016-07-27 13:02
well, it was beyond the renaming, it was a similar situation here where there was a certain mega-commit that imported the tree

ghaskins
2016-07-27 13:02
which means git-blame is blind beyond that point

simon
2016-07-27 13:02
it didn't import

simon
2016-07-27 13:02
it renamed and reshuffled things

ghaskins
2016-07-27 13:03
ok, fair enough

ghaskins
2016-07-27 13:03
but same effect

ghaskins
2016-07-27 13:03
lost history

ghaskins
2016-07-27 13:03
(or, inconvenient history, i should say)

simon
2016-07-27 13:03
almost - if git would try hard enough, it could follow it

simon
2016-07-27 13:03
now history is gone

ghaskins
2016-07-27 13:03
well, its not gone gone, its still in GH

simon
2016-07-27 13:04
gone from the new repo

ghaskins
2016-07-27 13:04
but inconvenient, yes

ghaskins
2016-07-27 13:04
agreed

ghaskins
2016-07-27 13:04
anyway, it sounds like its non-negotiable

ghaskins
2016-07-27 13:04
just a shame

simon
2016-07-27 13:05
great that the non-tech, non-developing people take technical decisions

simon
2016-07-27 13:06
cbf: so what's the strategy now for collaborative development of HUGE changes, like the new system architecture?

ghaskins
2016-07-27 13:09
@simon: reading between the lines and looking at the settings in gerrit, my guess is the driver is that future commits have to include a digital signature

ghaskins
2016-07-27 13:09
perhaps this is why they mandate a clean slate

cbf
2016-07-27 13:17
@ghaskins: LF wants to know that a) the author signed the DCO (part of accepting the LF membership) and b) who they are

kostas
2016-07-27 13:19
If you request a new password on the LF Identity website, you are never really given the new password. As such, you can never change the password manually. (You don't know the "current password", and requesting a new one via a reset email never actually reveals it to you.)

kostas
2016-07-27 13:19
Am I missing something here?

cbf
2016-07-27 13:19
@simon: I’m going to ignore that comment. we can use feature development branches (as we discussed in the F2F yesterday). Further, there is nothing preventing you from sharing your clone, either

simon
2016-07-27 13:20
sure, but how do we get these large changes in?

cbf
2016-07-27 13:20
@kostas, suggest you ping @tbenzies or @ry later about the login

simon
2016-07-27 13:21
kostas: log out, then reset password

cbf
2016-07-27 13:21
@simon I don’t understand what your issue is

simon
2016-07-27 13:22
cbf: say we need 200-500 commits to implement the new architecture to become as stable as what we have at the moment

simon
2016-07-27 13:22
cbf: that is a very big changeset

cbf
2016-07-27 13:22
each commit is independently reviewed

simon
2016-07-27 13:22
but do we review them at the end or while development is happening?

simon
2016-07-27 13:23
what's the best way to essentially break the code and put it back together in a different way?

cbf
2016-07-27 13:29
every commit creates its own review

cbf
2016-07-27 13:29
if you squash then there’s one, but NOBODY wants to review a bazillion lines of code

cbf
2016-07-27 13:30
a feature branch with maintainers reviewing and merging patches makes most sense

cbf
2016-07-27 13:30
or feature flags

simon
2016-07-27 13:31
right, so that in the end, we review while it is progressing

simon
2016-07-27 13:31
not 500 commits in one go

simon
2016-07-27 13:31
what's the procedure to get a new feature branch?

kostas
2016-07-27 13:33
(@cbf: Will do, thanks. @simon: Doing that doesn't reveal the new password, so you can never change the password to one of your own.)

simon
2016-07-27 13:33
as i said, log out

kostas
2016-07-27 13:33
I did.

simon
2016-07-27 13:33
then your reset password link will take you to a page that will not ask for a password

arnaud
2016-07-27 13:43
@cbf I have to agree with @simon on the IP aspect, it doesn't seem like forcing a single commit makes the situation really any better

arnaud
2016-07-27 13:44
at best it only forces a single party to take the blame for anything that happened before

arnaud
2016-07-27 13:45
which I imagine LF might like

arnaud
2016-07-27 13:46
but it doesn't make the actual pedigree any better

cbf
2016-07-27 14:16
take it up wth the LF legal team then, because we (and Intel) pushed back but they insisted

cbf
2016-07-27 14:24
@simon I think the appropriate process would be to request one on the mailing list and the maintainers will then need to make a collective decision… ideally a feature branch is associated with an agreed (feature) proposal

scottz
2016-07-27 14:31
has joined #fabric-dev

cbf
2016-07-27 16:43
@simon: @ghaskins just discussed with @binhn and @sheehan and they concur with the model I described above… we would limit to feature development that was collaborative and bigger than a breadbox. Would welcome your thoughts. Will run by @tamas and @hgabor shortly

ghaskins
2016-07-27 16:43
this makes sense to me

simon
2016-07-27 16:43
thanks

simon
2016-07-27 16:43
feature branch is fine with me

ghaskins
2016-07-27 16:43
obviously git is git, anyone can fork/push/whatever to something outside of gerrit

cbf
2016-07-27 16:44
y

ghaskins
2016-07-27 16:44
it mostly comes down to visibility/integration

simon
2016-07-27 16:44
yes

junzhang
2016-07-27 18:08
has joined #fabric-dev

andres
2016-07-27 18:23
is CI being triggered from Gerrit?


andres
2016-07-27 18:40
thanks ramesh. Is only jenkins working?

ramesh
2016-07-27 18:40
yes..

hgabor
2016-07-27 19:18
who could help me with vagrant?

cbf
2016-07-28 00:51
: I’m updating the docs to provide info on using Gerrit http://cbf-fabric-docs.readthedocs.io/en/latest/

cbf
2016-07-28 00:52
I should have this ready for Gerrit review tomorrow

cbf
2016-07-28 00:52
please feel free to send me any feedback

grapebaba
2016-07-28 06:22
how to reverify jenkins now?

lbonniot
2016-07-28 09:00
Hi everyone! I'm trying to understand the current status of the security features of fabric, and I have some questions. - A security context is provided after login on the membership service; and is sent for each transaction to peers. What is it, exactly? I've not found any documentation related to that. Is is some kind of Ecert? The peer binary does not seem to send any other "secure" information other than this security context. - In the current implementation, is the ACA working? This authority is not specified in the fabric protocol, and I'm wondering if I can use the ACA and the http://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#ChaincodeStub.VerifyAttribute function while only sending the security context in the chaincode invocation. - Basically, is it a good idea to start building things on top of the security features right now, or is it a better idea to wait for more stable API? Thanks

andres
2016-07-28 11:54
Hi lbonniot, A security context includes a CallerCert, it is a transaction certificate (TCert). ECert is generated at enroll time and before transaction the client request to the TCA per a batch of TCerts (the default value is 200 TCerts), the client invokes the chaincode using one of these TCerts in each invocation. When there is no more TCert, client invokes TCA again per a new batch. TCert keys are derived from ECert keys, in this way the client uses a different key in each invocation avoiding linkability. About ACA is working you can see a recently added documentation here https://github.com/hyperledger/fabric/blob/master/docs/API/AttributesUsage.md . You can start building on top of the security features, you can join in # channel where we can help you to address your questions

zuowang
2016-07-28 11:56
How to query system chaincode? I didn't find anything helpful here. https://github.com/hyperledger/fabric/blob/master/docs/SystemChaincodes/noop.md

zuowang
2016-07-28 11:56
curl -i -X POST -H "Content-Type: application/json" http://localhost:5000/chaincode -d '{ "jsonrpc": "2.0", "method": "query", "params": { "type": 1, "chaincodeID":{ "name":"noop" },"ctorMsg": { "function":"getTran", "args":["530923200208163348"] }, "secureContext":"B003003H8000" }, "id": 5}' result: {"jsonrpc":"2.0","error":{"code":-32003,"message":"Query failure","data":"Error when querying chaincode: Error:Failed to launch chaincode spec(Could not get deployment transaction for noop - LedgerError - ResourceNotFound: ledger: resource not found)"},"id":5}

lbonniot
2016-07-28 11:56
Thanks a lot @andres , I'll check that :slightly_smiling_face:

simon
2016-07-28 11:56
zuowang: did you enable the noop system chaincode?

zuowang
2016-07-28 11:58
simon: how to enable? like this? { Enabled: true, Name: "noop", Path: "http://github.com/hyperledger/fabric/bddtests/syschaincode/noop", InitArgs: []string{}, Chaincode: &noop.SystemChaincode{}, },

simon
2016-07-28 11:58
i don't really know

simon
2016-07-28 11:58
isn't there something in the config yaml file?

zuowang
2016-07-28 12:01
Thanks a lot! I didn't find any config in yaml file.

simon
2016-07-28 12:11
maybe that was removed

grapebaba
2016-07-28 12:26
@cbf: should I add reviewer on Gerrit by self? and where can add comment for change in Gerrit?I have migrated a PR

simon
2016-07-28 12:29
i find reviewing on gerrit extremely difficult

simon
2016-07-28 12:29
i can't see all changes on the same page

grapebaba
2016-07-28 12:39
yep, i also like github

hgabor
2016-07-28 13:06
hey

hgabor
2016-07-28 13:06
if anybody needs a reviewer please invite me

hgabor
2016-07-28 13:07
use my nickname 'hgabre' or my e-mail

hgabor
2016-07-28 13:08
now, I m reviewing changesets from the 'All open' tab

simon
2016-07-28 13:11
hgabor: is there a way to see changes across all files in one view?

hgabor
2016-07-28 13:13
simon: if you mean the classic github style view where one can see all the files under one another then I think there is no such view

simon
2016-07-28 13:13
who thinks of that?

simon
2016-07-28 13:13
of course i need to see all concurrently

hgabor
2016-07-28 13:15
I suggest you to click on the first file and then use the arrows to navigate - at the first look, it may be harder than github

simon
2016-07-28 13:19
the more difficult the interface, the less reviewing will take place

grapebaba
2016-07-28 13:21
@manish-sethi: what is your username in Gerrit? Need you review first i think

hgabor
2016-07-28 13:25
simon: I hope people will get used to it and will like it. I was in projects where we had Gerrit and for me it is much better than github. Much cleaner.

simon
2016-07-28 13:26
okay

simon
2016-07-28 13:26
hgabor: can you suggest some strategies?

simon
2016-07-28 13:32
seems i can only review +1/-1, not +2/-2

hgabor
2016-07-28 13:32
the one I use is the following: 1, read the commit message and get the general goal of the changeset (if it does not tell enough then it is a bad commit message) 2, go over all the files and check higher level things like formatting (whitespaces have a red background etc. so it is easy to see), what files were modified, whether the tests were updated and the higher level structure of the modification 3, go over once again and try to understand the changes (lower level). I often use multiple tabs for the multiple, related files While doing this, one can add comments, tips etc.

simon
2016-07-28 13:36
okay, while we're talking about reviews

hgabor
2016-07-28 13:36
Only maintainers (now called "committers" in Gerrit terminology if I am right) can give +2. But I think it is very important to give +1/-1 to those changesets that you review because it will help maintainers give +2 and merge. Maybe one could also write comments like "I had a deeper look and the changes are totally OK" to indicate that one is an expert of the topic (while the maintainers are not always experts of all the topics).

simon
2016-07-28 13:37
how stickly do we want to be about different semantic changes being mixed into one commit?

simon
2016-07-28 13:37
yea, i should be a maintainer, but i am not

simon
2016-07-28 13:37
@ry: can you check? my lf id is `corecode`

hgabor
2016-07-28 13:43
I think we should not mix semantic changes.

hgabor
2016-07-28 13:44
But if you have a PR that has already have them then that may be OK. But in the future we should avoid them I think.

simon
2016-07-28 13:49
i try to keep my commits as small as possible

simon
2016-07-28 13:49
hgabor: can one proposed change consist of multiple commits?

hgabor
2016-07-28 13:52
Yeah but now we have dozens of PRs that need to be migrated to Gerrit. And now I am trying to find out the best way of migration for one of my PRs. As you may know a commit from a PR equals 1 changeset in Gerrit. So if one wants to create 1 changeset from a PR then a squash is needed.

hgabor
2016-07-28 13:52
Sorry I just read it. So the answer is no, it cannot. 1 changeset = 1 commit.

hgabor
2016-07-28 13:53
It is a smaller thing than the PR concept of GitHub. But one can have a chain of changesets (like a chain of commits).

simon
2016-07-28 13:59
what?

simon
2016-07-28 13:59
that's terrible

simon
2016-07-28 13:59
or will it all be one "subject"

simon
2016-07-28 13:59
with multiple changesets?

hgabor
2016-07-28 14:02
what exactly do you mean by subject?


simon
2016-07-28 14:02
says "subject"

hgabor
2016-07-28 14:03
yeah now I get it

hgabor
2016-07-28 14:03
no, with different subjects

simon
2016-07-28 14:03
so if i implement a feature in 10 small commits, then there will be 10 lines?

hgabor
2016-07-28 14:05
yes

hgabor
2016-07-28 14:06
but these should be merged much quicker and 'smoother' than PRs

simon
2016-07-28 14:06
lol

simon
2016-07-28 14:06
this project is doomed

hgabor
2016-07-28 14:07
if you change an existing feature why would it make any harm to have N changesets? (where N >= 10)

simon
2016-07-28 14:07
it's fine to have N commits

simon
2016-07-28 14:07
mandatory even

simon
2016-07-28 14:07
but a list where these are no longer grouped together

simon
2016-07-28 14:07
but floating around independent of each other...

hgabor
2016-07-28 14:07
they are grouped together but not in that list

simon
2016-07-28 14:08
okay

hgabor
2016-07-28 14:08
if you open one of the commits (changesets) you can see all the others from the chain (depending on it or dependencies)

simon
2016-07-28 14:08
i'll venture a guess:

simon
2016-07-28 14:09
all will run sort of okay until there is an IBM bluemix release, or something like that

simon
2016-07-28 14:09
suddenly there will be the need to fix a lot of things in a short time

simon
2016-07-28 14:09
and then there either will be dozens or hundreds of half okay changesets proposed

simon
2016-07-28 14:10
or implementations will diverge, because gerrit cannot keep up with the creation of changesets

hgabor
2016-07-28 14:10
5 minutes and I will be back and answer :slightly_smiling_face:

cbf
2016-07-28 14:13
@simon yep it's doomed, just like openstack ... not - you'll get used to it. go read how openstack uses it. google is your friend.

simon
2016-07-28 14:14
i think review is essential

simon
2016-07-28 14:14
my fear is that at some point a deadline will push to diverge code bases

hgabor
2016-07-28 14:19
@cbf it would be good to some wikis/slides about the best practices of Gerrit. Maybe Ry could help us with them.

hgabor
2016-07-28 14:20
@simon half okay changesets: we need cool CI and lots of reviews and that won't happen :slightly_smiling_face:

simon
2016-07-28 14:21
no, they will happen anyways

simon
2016-07-28 14:21
it's just that via gerrit we can prevent those to land in the repo

hgabor
2016-07-28 14:21
@simon how would implementations diverge? on github if everybody has a fork it is easy to have divergent implementations

hgabor
2016-07-28 14:22
@simon yep I meant the prevention thing

hgabor
2016-07-28 14:23
ok and I will write no more at_simon as there is too much now here :slightly_smiling_face:

ry
2016-07-28 14:23
@simon: is your email @zurich.ibm.com?

simon
2016-07-28 14:23
well, as long as we can get managements to accept that the gerrit repo is the only source of code, that's fine

simon
2016-07-28 14:23
ry: yes, i added both the ibm address and the github openid one

hgabor
2016-07-28 14:23
what about mirroring it to github? as I remember it was planned to have such a feature

ry
2016-07-28 14:24
@simon: I sent the invite to your IBM address

simon
2016-07-28 14:24
ry: should i have accepted the invite before registering with gerrit?

ry
2016-07-28 14:24
simon: no, I don’t think you could have

cbf
2016-07-28 14:34
@hgabor: - I have a bunch of info in the works... hope to push this afternoon

hgabor
2016-07-28 14:35
@cbf you mean about gerrit and such things?

cbf
2016-07-28 14:35
yep

hgabor
2016-07-28 14:36
sounds good

cbf
2016-07-28 14:36
new content in contributing and index in left hand margin

cbf
2016-07-28 14:36
lmk if you have any feedback... not complete... gathering from other projects

grapebaba
2016-07-28 14:41
@hgabor: I saw you comment for my change, i am not familiar with gerrit. Could you tell me how to change my commit message?Does it need a new patchset?

cbf
2016-07-28 14:42
git commit --amend

cbf
2016-07-28 14:42
then push again

hgabor
2016-07-28 14:42
@grapebaba you have two options 1, check it out and use amend 2, use the icon

hgabor
2016-07-28 14:44
I am not sure that option two is still present in Gerrit. I meant that there somewhere one can find a small pencil icon which is called 'Edit commit message'. @ry do we still have such a feature? on the GUI

ry
2016-07-28 14:44
@hgabor: I don’t know if it is enabled by default

hgabor
2016-07-28 14:45
@ry where to enable?

simon
2016-07-28 14:45
amend commit is better anyways to adapt for other review remarks

simon
2016-07-28 14:45
something to get familiar with

cbf
2016-07-28 14:45
yep

hgabor
2016-07-28 14:45
btw @grapebaba note that using git commit --amend will create a new patchset and you will be able to view all your patchsets under one changeset which is cool :slightly_smiling_face:

grapebaba
2016-07-28 14:45
ok

ry
2016-07-28 14:45
hgabor: I mean it may not be enabled on Gerrit at all by default

cbf
2016-07-28 14:47
@simon: poke around Settings - there are different ways to configure the review ux

simon
2016-07-28 14:48
ah thanks

hgabor
2016-07-28 14:50

simon
2016-07-28 14:51
meh

simon
2016-07-28 14:52
i'd rather have gerrit integration in my editor :slightly_smiling_face:

ry
2016-07-28 14:54
Gerrit has a REST api: https://gerrit-review.googlesource.com/Documentation/rest-api.html would probably allow that

simon
2016-07-28 14:56
so there is a git-review thing

simon
2016-07-28 14:57
and magit-gerrit for emacs

ry
2016-07-28 14:57
yes git-review is very popular

ry
2016-07-28 15:28
@cbf: you might want to reference http://chris.beams.io/posts/git-commit/#seven-rules (or incorporate it)

cbf
2016-07-28 15:28
ok thx @ry

cbf
2016-07-28 15:30
@simon ping Brad Topol or Steve Martinelli - they can give you all kinds of insights into gerrit use at openstack

cbruguera
2016-07-28 15:31

cbruguera
2016-07-28 15:31
Did anyone check that out?

ghaskins
2016-07-28 15:43
@cbruguera: IIUC, I think the issue isn’t purely “we want Gerrit”, but rather there is some legal ramifications for things such as how the changesets are processed into the tree, etc, that LF requires governance over

ghaskins
2016-07-28 15:43
therefore, I think part of the story is the project needs to be hosted in http://hyperledger.org control

ghaskins
2016-07-28 15:43
thats just me reading between the lines, not sure I got that right

cbruguera
2016-07-28 15:48
I understand.

cbruguera
2016-07-28 15:49
Well I'm not 100% acquainted with the particular nuances of hyperledger development. I just thought it was a matter of gerrit providing a more powerful code review tool currently lacking on github.

cbruguera
2016-07-28 15:50
So I thought that might be useful, since it probably allows you to keep using github while leverating gerrit... After all, github has a lot of nice features, specifically when dealing with usability.

ghaskins
2016-07-28 15:50
well, that is part of it

ghaskins
2016-07-28 15:51
but if that were the _only_ issue, gerrithub might have been a good option

cbruguera
2016-07-28 15:51
I see..

ghaskins
2016-07-28 15:51
im just saying, its more complicated than that

ry
2016-07-28 15:51
ghaskins: the key issue is provenance. we can enforce DCO assertion with Gerrit easily

ghaskins
2016-07-28 15:51
(or, thats my take, I should say)

ghaskins
2016-07-28 15:52
@ry, right, thats my understanding, but I also thought there was a requirement for DCO domain such as being tied to an LF identity, etc

ghaskins
2016-07-28 15:53
(i.e. its not just the mere presence of DCO, but the provenance of the DCO being something we know the user has agreed to LF mandated terms, etc

ry
2016-07-28 15:53
@ghaskins: when you sign up for an LFID you are jumping through the “sign the DCO” hoop

ry
2016-07-28 15:53
yes, you’re right

ghaskins
2016-07-28 15:54
im also guessing that would be harder/impossible to enforce with something like http://gerrithub.io vs http://gerrit.hyperledger.org

ghaskins
2016-07-28 15:54
but, not as sure about that

simon
2016-07-28 15:55
service as a service!

hgabor
2016-07-28 15:55
why can I get errors like these? go install http://github.com/hyperledger/fabric/core/crypto/attributes/proto: open /opt/gopath/pkg/linux_amd64/github.com/hyperledger/fabric/core/crypto/attributes/proto.a: permission denied go install http://github.com/hyperledger/fabric/core/util: open /opt/gopath/pkg/linux_amd64/github.com/hyperledger/fabric/core/util.a: permission denied go install http://github.com/hyperledger/fabric/membersrvc/protos: open /opt/gopath/pkg/linux_amd64/github.com/hyperledger/fabric/membersrvc/protos.a: permission denied

hgabor
2016-07-28 15:55
when compiling

simon
2016-07-28 15:55
agricultural -> industrial -> service -> meta service economy

simon
2016-07-28 15:55
what's next

ghaskins
2016-07-28 15:55
@hgabor: one thing that might be happening is that the build was initially performed as root (such as by the vagrant setup.sh

simon
2016-07-28 15:56
hgabor: your /opt/gopath is not writable by your owner

ghaskins
2016-07-28 15:56
is this within vagrant?

ry
2016-07-28 15:56
I’m providing customer service for the service ||: as a service : ||

ghaskins
2016-07-28 15:56
(actually, i think vagrant setup.sh does a chown

simon
2016-07-28 15:56
hehe

hgabor
2016-07-28 15:56
@ghaskins: yes it is in vagrant

ghaskins
2016-07-28 15:56
check the perms of that .a

hgabor
2016-07-28 15:56
it it seemed that vagrant up was successful

ghaskins
2016-07-28 15:57
my guess is it was owned by root

ghaskins
2016-07-28 15:57
now the question is, why?

ry
2016-07-28 15:57
hgabor: the root ownership bug was fixed a while ago

ghaskins
2016-07-28 15:57
@ry, this looks like a host build problem

hgabor
2016-07-28 15:57
this is for the gerrit repo

ghaskins
2016-07-28 15:57
e.g. its not in the fabric/build, but rather top level /opt/gopath

ry
2016-07-28 15:58
I will step aside :slightly_smiling_face:

ghaskins
2016-07-28 16:04
@ry, i didn’t mean it that way, your input is always welcome

ghaskins
2016-07-28 16:05
(actually you were the one that caught the docker-level problem last time, so I appreciate your eyes here)

ghaskins
2016-07-28 16:05
but as far as I can tell, I _think_ this is host-level this time

ghaskins
2016-07-28 16:18


hgabor
2016-07-28 16:18
yes

ghaskins
2016-07-28 16:19
do you have a prompt that looks like "vagrant@hyperledger-devenv:v0.0.10-667d977:~$"

ghaskins
2016-07-28 16:19
or does it look like vagrant@ubuntu

ghaskins
2016-07-28 16:19
?

hgabor
2016-07-28 16:20
look

hgabor
2016-07-28 16:20
vagrant@ubuntu-1404:/opt/gopath/src/github.com/hyperledger/fabric$ echo "needed prompt: vagrant@hyperledger-devenv:v0.0.10-667d977:~$"

hgabor
2016-07-28 16:20
so as you see I have the ubuntu one

ghaskins
2016-07-28 16:21
yeah, so your environment is messed up

ghaskins
2016-07-28 16:21
i suspect that happened is it failed in the compilation step

ghaskins
2016-07-28 16:21
so, that would mean the “go install” wrote packages to /opt/gopath/pkg as root, but the chown never ran

hgabor
2016-07-28 16:22
yep

hgabor
2016-07-28 16:22
so destroy vagrant, up vagrant?

ghaskins
2016-07-28 16:22
as per here


ghaskins
2016-07-28 16:22
well, you can do that yes

ghaskins
2016-07-28 16:23
if you want, you can just run the rest of those steps from L99 down

ghaskins
2016-07-28 16:23
whatever you feel like

ghaskins
2016-07-28 16:23
We have a PR outstanding that will make this more obvious that your environment is toast

ghaskins
2016-07-28 16:23
but it hasnt been merged yet, I probably need to resubmit it to Gerrit

hgabor
2016-07-28 16:24
destroy vagrant seems to be easier for me

ghaskins
2016-07-28 16:25
sounds good, thx

ghaskins
2016-07-28 16:25
if you dont get the vagrant@hyperledger prompt, save off the vagrant log

hgabor
2016-07-28 16:26
'running inline script' I guess this part runs setup.sh

hgabor
2016-07-28 16:29
it seems that it is OK

hgabor
2016-07-28 16:29
the inline script

ghaskins
2016-07-28 16:32
correct

ghaskins
2016-07-28 16:32
to be clear, i think it did partially run

ghaskins
2016-07-28 16:32
it just didnt complete

ghaskins
2016-07-28 16:32
unfortunately, the system is not super clear when that occurs

ghaskins
2016-07-28 16:33
there is a PR to address this, because people keep stumbling into it

hgabor
2016-07-28 16:37
after the vagrant is up, we will see

simon
2016-07-28 17:21
-_- who keeps writing code that logs transaction content?

hgabor
2016-07-28 17:27
what code do you mean?

simon
2016-07-28 17:28
oh this actually was a problem of an unexpected log

simon
2016-07-28 17:28
the system suddenly output a whole deployment transaction

simon
2016-07-28 17:28
turns out `ledger.RollbackTxBatch(id interface{})` prints the id...

hgabor
2016-07-28 17:32
simon, what will happen to your consensus separation feature branch?

simon
2016-07-28 17:34
we hope that we will get a feature branch in gerrit

simon
2016-07-28 17:34
or decide that we destabilize master for a while

hgabor
2016-07-28 17:36
my opinion is that it may be OK to have a branch for such a big feature

hgabor
2016-07-28 17:36
but merging can be difficult and keeping uptodate

simon
2016-07-28 17:37
i think we should look into splitting the repo into smaller things

hgabor
2016-07-28 17:38
do you mean more than one repos?

simon
2016-07-28 17:39
yes

simon
2016-07-28 17:39
maybe break out some libraries

simon
2016-07-28 17:39
client sdk, membership services

simon
2016-07-28 17:40
different consensus implementations

simon
2016-07-28 17:40
chaincode shim

simon
2016-07-28 17:40
protobuf api definitions

hgabor
2016-07-28 17:45
client sdk and membership services - it would be a good idea to put those to other repos

hgabor
2016-07-28 17:46
but then we need integration tests

simon
2016-07-28 17:53
oh yes, they would also be in a separate repo

hgabor
2016-07-28 17:58
that would be okay but maybe it would make testing harder

simon
2016-07-28 17:59
why?

hgabor
2016-07-28 18:07
because it would imply that you cannot run some tests on your own machine

hgabor
2016-07-28 18:08
(more precisely you can but you have to have all the needed repos and a special environment)

hgabor
2016-07-28 18:09
think of the behave tests, I dunno if there is any bdd test working with membersvc but if membersvc was in another repo then it made running bdd tests harder

hgabor
2016-07-28 18:09
don't you think?

simon
2016-07-28 18:10
no

simon
2016-07-28 18:10
the integration tests repo would contain scripts to build docker images and run the tests

hgabor
2016-07-28 18:12
oh good idea,

hgabor
2016-07-28 18:12
but that part remains true that you will have to have all the repos

simon
2016-07-28 18:22
sure

simon
2016-07-28 18:23
but i think if we break apart repos, we can't use vendoring

simon
2016-07-28 18:23
or at least can't pass vendor data structures between different code parts

hgabor
2016-07-28 18:24
btw isn't that an antipattern? vendoring

ghaskins
2016-07-28 18:26
@hgabor: I am too new to golang to know what is considered anti-pattern, but I can say that I think the golang concept of dependency specification is a bit broken and vendoring is the only semblance of sanity I have come across

hgabor
2016-07-28 18:26
ghaskins, go downloads things from the github, right?

hgabor
2016-07-28 18:27
so it has no real version control

simon
2016-07-28 18:27
it does, and you can't specify a version

ghaskins
2016-07-28 18:27
yeah, they totally bungled that aspect of the language

simon
2016-07-28 18:27
somebody changes the API, poof

hgabor
2016-07-28 18:27
yep then really vendoring is needed

ghaskins
2016-07-28 18:27
systems like maven(leiningen) and npm do a much better job here

hgabor
2016-07-28 18:27
isnt there any fix for that? I mean some workaround or anything

ghaskins
2016-07-28 18:28
yeah, vendoring :wink:

ghaskins
2016-07-28 18:28
there was one alternative I looked at

ghaskins
2016-07-28 18:28
let me see if I can find it

ghaskins
2016-07-28 18:29
this was it:

ghaskins
2016-07-28 18:29

ghaskins
2016-07-28 18:29
it was somewhat promising because you could essentially add a version coordinate to normal http://github.com/golang things

ghaskins
2016-07-28 18:30
but its not foolproof, it only works if the upstream author happens to maintain tags well, etc

hgabor
2016-07-28 18:30
it would be good if one could use git hashes, no?

ghaskins
2016-07-28 18:31
yeah, i seem to recall you cant though

ghaskins
2016-07-28 18:31
that seems like a good feature though

ghaskins
2016-07-28 18:31
i dont remember, it was a while ago and we decided a short while later to switch to vendoring

ghaskins
2016-07-28 18:31
(which has its own set of problems)

ghaskins
2016-07-28 18:32
but does seem to be about as good as you can get within golang

hgabor
2016-07-28 18:32
okay I see, the problem is golang

ghaskins
2016-07-28 18:32
yeah

hgabor
2016-07-28 18:32
and its funny "package/dep management"

ghaskins
2016-07-28 18:33
yeah, i never bothered to research why it was done the way it was done

ghaskins
2016-07-28 18:33
perhaps there was a valid argument

ghaskins
2016-07-28 18:34
but it seems fairly braindead from my perspective

hgabor
2016-07-28 18:34
I dont think there could be any

ghaskins
2016-07-28 18:35
anyway, to your point, without upstream participation, SHAs are really your best coordinate mechanism

ghaskins
2016-07-28 18:35
and vendoring is the only way I am aware of to get that

ghaskins
2016-07-28 18:36
(indirectly, anyway)

ghaskins
2016-07-28 18:36
more like “sha coordinates by brute force”, heh

hgabor
2016-07-28 18:36
wasnt it enough to have shell scripts that would download all the vendor packages?

hgabor
2016-07-28 18:36
or do we have artifactory or something like that?

ghaskins
2016-07-28 18:37
you could probably do that, rather than use go-get you mean?

hgabor
2016-07-28 18:37
yes I meant that

ghaskins
2016-07-28 18:37
one problem is that it isnt just about the coordinate, but also about the context

ghaskins
2016-07-28 18:37
vendoring means that you can have different deps for different subsystems (with some obvious limitations)

hgabor
2016-07-28 18:38
do we use this feature of vendoring?

hgabor
2016-07-28 18:38
if yes, where

ghaskins
2016-07-28 18:38
but for example, say projects foo and bar both use a logger, but use diffferent versions of it

ghaskins
2016-07-28 18:38
and foo uses bar

ghaskins
2016-07-28 18:38
with vendoring, foo and bar can each bring in their own, theoretically at least

hgabor
2016-07-28 18:38
yeah yeah yeah I get it, but in our project, do we have such subsystems?

ghaskins
2016-07-28 18:39
not sure, but probably

ghaskins
2016-07-28 18:39
i think we were primarily interested in stable coordinates

ghaskins
2016-07-28 18:39
but there could be some heterogeneity too if we broke out the digraph

hgabor
2016-07-28 18:40
but how can you do this foo bar thing with vendoring? doesnt it mean just putting all the vendor things under a vendor directory?

ghaskins
2016-07-28 18:41
well, if I had bar/vendor/logger(v2) and foo/vendor/[logger(v3), bar] for instance

ghaskins
2016-07-28 18:41
the system applies context

hgabor
2016-07-28 18:41
and what does go do with this structure?

ghaskins
2016-07-28 18:42
the vendor directory has hierarchical significance, IIUC

ghaskins
2016-07-28 18:42
so, under “bar” v2 would be in effect

ghaskins
2016-07-28 18:42
v3 elsewhere in foo

ghaskins
2016-07-28 18:42
etc

hgabor
2016-07-28 18:42
how does go know which is bar? does it have to be named bar.go?

ghaskins
2016-07-28 18:43
not sure I understand your question

ghaskins
2016-07-28 18:43
its package name based

ghaskins
2016-07-28 18:43
generally its the dirname that matters

ghaskins
2016-07-28 18:43
not the .go files

hgabor
2016-07-28 18:43
okay okay that was the question

hgabor
2016-07-28 18:44
but in vendor directory, there are no directories the name of which is a module name

ghaskins
2016-07-28 18:44
in go, if I had $GOPATH/src/bar/[bat.go, baz.go], I am implicitly bringing both files in by saying “import bar"

ghaskins
2016-07-28 18:45
i think its a fqp

ghaskins
2016-07-28 18:46
for instance


ghaskins
2016-07-28 18:46
I could say “import ‘http://github.com/kr/pretty'"

ghaskins
2016-07-28 18:46
and it would be satisfied by $mypkg/vendor first, or $GOPATH/src second

ghaskins
2016-07-28 18:47
(falling back to trying to git-cloning it if those fail)

ghaskins
2016-07-28 18:47
thats why I said its contextual via the heirarchy

ghaskins
2016-07-28 18:48
anything under $mypkg has its imports aliased to $mypkg/vendor (if it exists)

hgabor
2016-07-28 18:48
okay then I will have to search for directories called vendor

hgabor
2016-07-28 18:52
we only have these

hgabor
2016-07-28 18:52
./build/docker/pkg/linux_amd64/github.com/hyperledger/fabric/vendor ./vendor

ghaskins
2016-07-28 19:16
not sure what you are trying to do

ghaskins
2016-07-28 19:16
note that ./build is just a transient artifact directory

hgabor
2016-07-28 19:22
I know that

hgabor
2016-07-28 19:22
I meant that we only use /vendor for the full project but there are no overrides

ghaskins
2016-07-28 19:22
sorry, i am not clear on what you are after

ghaskins
2016-07-28 19:23
oh, i see what you are doing

ghaskins
2016-07-28 19:23
you are looking for vendoring within one of our vendored packages?

hgabor
2016-07-28 19:23
yep exactly

ghaskins
2016-07-28 19:23
ok, sorry, i get it now

hgabor
2016-07-28 19:24
my guess is that as we only use a project-wide vendor dir, we could also use shell scripts with exact git hashes (those script could fetch the vendor package at build time)

ghaskins
2016-07-28 19:24
probably…what problem are you trying to solve?

hgabor
2016-07-28 19:24
(or we could create a gradle plugin to do that etc etc... :slightly_smiling_face: )

hgabor
2016-07-28 19:25
I do not know if this is a problem for others but we store the repos of other vendors in our own repo, dont we?

hgabor
2016-07-28 19:25
this is one of the disadvantages of vendoring

ghaskins
2016-07-28 19:25
yes, but that is the whats intended with vendoring

hgabor
2016-07-28 19:25
yep but it could be workarounded

ghaskins
2016-07-28 19:26
while perhaps wasteful, I dont see it as particularly problematic

hgabor
2016-07-28 19:26
but I am OK with the current situation if everybody likes this

hgabor
2016-07-28 19:26
yep, kinda wasteful

ghaskins
2016-07-28 19:26
heh, well, to be clear, I wish golang just had a more reasonable dep system

ghaskins
2016-07-28 19:27
so I wouldnt say I “like this” :wink:

hgabor
2016-07-28 19:27
yes I wish too but I guess we will have to wait some decades for that

ghaskins
2016-07-28 19:27
but it does seem to be the way golang is supposed to work

hgabor
2016-07-28 19:27
I guess the idea behind it is that golang programmers have to write backward compatible code

hgabor
2016-07-28 19:27
including APIs

ghaskins
2016-07-28 19:28
the biggest issue I have seen is sometimes people inadvertently patch the vendored code, such as an errant gofmt run

hgabor
2016-07-28 19:28
yeah and I think this has something to do with the fact that we have the code of others in our repo

ghaskins
2016-07-28 19:32
well, that would be typically with vendoring though


hgabor
2016-07-28 19:34
does anybody have any idea what's the error there? I do not see any error


hgabor
2016-07-28 19:37
oh thx ramesh

hgabor
2016-07-28 19:38
isn't that an unstable test?

ramesh
2016-07-28 19:42
not sure..but seems failure is related to timeout issue..

hgabor
2016-07-28 19:43
to be honest I have tried all the test on my local machine and they worked fine

hgabor
2016-07-28 19:44
can I retrigger that Jenkins job?

ramesh
2016-07-28 19:45
No I think.. Do you see `retrigger` option in jenkins?

hgabor
2016-07-28 19:46
no :disappointed:

ramesh
2016-07-28 19:47
will do that now..

ramesh
2016-07-28 19:47
done

hgabor
2016-07-28 19:47
thanks

hgabor
2016-07-28 19:48
is it possible somehow to create a retrigger option?

ramesh
2016-07-28 19:49
that comes with user permissions in jenkins..

hgabor
2016-07-28 19:50
what if I had a Jenkins user? would I be able to retrigger?

hgabor
2016-07-28 19:51
could I get the proper permissions?

ramesh
2016-07-28 19:52
I am not sure but please check with ry..

hgabor
2016-07-28 19:52
okay

hgabor
2016-07-28 19:53
thanks ramesh

hgabor
2016-07-28 20:42
now it is a +1 so it was test instability

hgabor
2016-07-28 20:43

jcarrivick
2016-07-29 01:38
So should we be manually be adding reviewers or will that happen automatically?

jcarrivick
2016-07-29 01:39
I just published a draft change and the `Hyperledger Jobbuilder` didn't get added

jcarrivick
2016-07-29 01:42
just added it manually though

ry
2016-07-29 01:57
you need to manually add people

ry
2016-07-29 01:59
@jcarrivick: it looks like you’re going to have some conflicts as well (click the conflicts tab) https://gerrit.hyperledger.org/r/#/c/273/2

ry
2016-07-29 02:00
@jcarrivick: the build for your change is behind one other build: https://jenkins.hyperledger.org/view/fabric/

jcarrivick
2016-07-29 02:01
Sweet, thanks @ry

jcarrivick
2016-07-29 02:01
for those conflicts, should I wait until the other changes are merged to fix them?

ry
2016-07-29 02:01
jcarrivick: draft change means something special in gerrit land, I apologize for my confusion

ry
2016-07-29 02:02
I would wait

jcarrivick
2016-07-29 02:03
great :slightly_smiling_face:

jcarrivick
2016-07-29 02:03
One other question from your comments there, gerrit likes commit message lines to be <70 chars?

grapebaba
2016-07-29 02:05
what about issues now? submit in JIRA?

ry
2016-07-29 02:07
grapebaba: for fabric and sawtooth lake, yes

ry
2016-07-29 02:07
I haven’t set up fabric-api project yet

grapebaba
2016-07-29 02:08
:ok_hand::skin-tone-6:

ry
2016-07-29 02:09
there will be an import in the future but I’m not sure when - in weeks, not days or months

grapebaba
2016-07-29 02:27
ry, another question. How to find the jenkins build number in gerrit?

ry
2016-07-29 02:34
@grapebaba: look in comments at bottom of change

ry
2016-07-29 02:34
Bottom of page

grapebaba
2016-07-29 02:38
:cool:

grapebaba
2016-07-29 03:30
how to add a specific reviewer

grapebaba
2016-07-29 03:30
cannot find username

bgorman
2016-07-29 03:32
does anyone here use the HTTP endpoint for Git on Gerrit? I seem to get a lot of authentication failures with the same username and password that I log into the website with

bgorman
2016-07-29 03:33
I can see it posting to https://gerrit.hyperledger.org/r/fabric/info/refs?service=git-receive-pack (encrypted obviously) but rejects my credentials... same happens in my browser, but works with https://gerrit.hyperledger.org/r/

bgorman
2016-07-29 03:34
and before anyone suggests the SSH endpoint... I haven't figured out how to use SSH through a HTTP proxy

grapebaba
2016-07-29 03:50
@ramesh: that bdd test always failure

manish-sethi
2016-07-29 05:08
@grapebaba: I am just familiarising myself with Gerrit. I’ll create an Id today if it needs one

grapebaba
2016-07-29 05:10
:ok_hand::skin-tone-2:

simon
2016-07-29 09:44
@muralisr: what is the chaincode init function used for? i always thought it was used to set initial values for deploy

simon
2016-07-29 09:45
but it seems it gets invoked every time the container is launched again?

mihaig
2016-07-29 10:53
has joined #fabric-dev

grapebaba
2016-07-29 12:25
now how to reverify Jenkins?

muralisr
2016-07-29 12:36
@simon init should not be used when startign the container later (such as for an invoke or query)

simon
2016-07-29 12:36
which part of the code sends init?

muralisr
2016-07-29 12:37
chaincode_support.go … I think under Launch(..)

simon
2016-07-29 12:40
`sendInitOrReady`?

muralisr
2016-07-29 12:58
right

muralisr
2016-07-29 12:59
Ready is for restarting container for invoke or query

simon
2016-07-29 13:00
ah so the logic is hidden somewhere in there

simon
2016-07-29 13:00
bit of a spaghetti

muralisr
2016-07-29 13:05
its basically a state machine thing

muralisr
2016-07-29 13:10
move to ready state when starting up … go through init first if deploying

muralisr
2016-07-29 13:10
what are you running into ?

ghaskins
2016-07-29 13:13
@cbf: we still need to merge the developer-preview branch to gerrit

simon
2016-07-29 13:21
muralisr: i'm rewriting it to store deployment transactions in the ledger instead of pulling them out of the chain

muralisr
2016-07-29 13:22
did you check with @manish-sethi ?

muralisr
2016-07-29 13:22
I think he may done that at one point when were exploring upgrade

sanchezl
2016-07-29 14:25
has joined #fabric-dev

pmullaney
2016-07-29 15:38
@cbf: is there a requirement to have more than one reviewer in the new gerrit process? Or has that not been decided yet?

cbf
2016-07-29 15:56
that is the intended practice

cbf
2016-07-29 15:56
I need to check with LF to see if it has been implemented as a rule yet

ry
2016-07-29 16:17
@bgorman: you don’t use the same password. go to https://gerrit.hyperledger.org/r/#/settings/http-password to set or get your http password

ry
2016-07-29 16:19
@grapebaba: log in to jenkins, go to the build you want to re-run. there should be a “retrigger” button on the far left menu. your credentials are the same for gerrit as they are for jenkins.

hgabor
2016-07-29 16:44
everyone We have this: https://gerrit.hyperledger.org/r/#/c/317 Please have a look at the comments in this file and help us decide how to continue with this commit: https://gerrit.hyperledger.org/r/#/c/317/1/core/chaincode/shim/java/src/main/java/org/hyperledger/java/shim/ChaincodeStub.java The question is that we should use []byte or [][]byte as chaincode arguments?

tsariounov
2016-07-29 18:02
has joined #fabric-dev

kostas
2016-07-29 19:31
FWIW, Protocol Buffers v3.0.0 is out: https://github.com/google/protobuf/releases/tag/v3.0.0

ry
2016-07-30 01:51
you can add https://gerrit.hyperledger.org/r/#/admin/groups/9,members to reviews to add the fabric maintainers to a change cr-fabric

yaoguo
2016-07-30 05:48
has joined #fabric-dev

s.matthew.english
2016-07-30 14:24
@s.matthew.english uploaded a file: https://hyperledgerproject.slack.com/files/s.matthew.english/F1WMLFMG9/12121j2kkkmm123.png and commented: this is the error I get then trying to build from the IBM-Blockchain/learn-chaincode example

s.matthew.english
2016-07-30 15:20
ok nevermind that error

s.matthew.english
2016-07-30 15:20
I fixed it

s.matthew.english
2016-07-30 15:20
but is it possible to play with this locally?


s.matthew.english
2016-07-30 15:38
but also with the interface?

s.matthew.english
2016-07-30 15:38
I was looking at this


s.matthew.english
2016-07-30 15:39
is it possible with that one/

s.matthew.english
2016-07-30 15:39
yeah I did all that

cbf
2016-07-30 15:39
that repository was deprecated months ago

s.matthew.english
2016-07-30 15:39
from the link you sent me

s.matthew.english
2016-07-30 15:39
I've built and run it locally

s.matthew.english
2016-07-30 15:39
and I rewrote the functions inside of chaincode_start.go

s.matthew.english
2016-07-30 15:39
and there was no error

s.matthew.english
2016-07-30 15:40
but now I want to run it

s.matthew.english
2016-07-30 15:40
with some interface, or not

s.matthew.english
2016-07-30 15:40
but just to play with the functions

s.matthew.english
2016-07-30 15:40
run it on local host

s.matthew.english
2016-07-30 15:40
or w/e

cbf
2016-07-30 15:40
I don’t understand “run it with some interface or not"

s.matthew.english
2016-07-30 15:40
at the end of this...

s.matthew.english
2016-07-30 15:40

cbf
2016-07-30 15:40
that is also dated

cbf
2016-07-30 15:40
use the info at the link I provided

s.matthew.english
2016-07-30 15:40
under 'Interacting with Your First Chaincode'

cbf
2016-07-30 15:41
a) that is oriented to bluemix, and b) a bit dated


cbf
2016-07-30 15:41
that will allow you to run the chaincode locally and iteratively dev/test

s.matthew.english
2016-07-30 15:41
I already did that I think

cbf
2016-07-30 15:42
plus makes it easier to debug

s.matthew.english
2016-07-30 15:42
I wanted to play with the marbles demo

s.matthew.english
2016-07-30 15:42
but in the docs for the marbles demo

s.matthew.english
2016-07-30 15:42
it said first check out that 'learn chaincode "hello world"' thing

cbf
2016-07-30 15:42
you need to port marbles, cp or car lease demos

cbf
2016-07-30 15:42
they were written as CF apps

s.matthew.english
2016-07-30 15:42
what do you mean by port

cbf
2016-07-30 15:43
you need to do a little work to get them to run locally

s.matthew.english
2016-07-30 15:43
is there any kind of

s.matthew.english
2016-07-30 15:43
docs?

s.matthew.english
2016-07-30 15:43
about how to do that

s.matthew.english
2016-07-30 15:43
BlueMix is somewhat unstable

s.matthew.english
2016-07-30 15:46
at least for me- who is outside of IBM

cbf
2016-07-30 15:47
actually, looks like the guys already made some changes but didn’t update the docs

cbf
2016-07-30 15:47
you can run marbles locally

s.matthew.english
2016-07-30 15:47
yeah i'd like to

cbf
2016-07-30 15:47
it will be on localhost:3000

s.matthew.english
2016-07-30 15:47
I want to get involved with this project

cbf
2016-07-30 15:47
cool! glad to have the extra hands

s.matthew.english
2016-07-30 15:47
ok so- just run it according to the GitHub?

s.matthew.english
2016-07-30 15:48
yeah man- I think it's interesting

s.matthew.english
2016-07-30 15:48
it's a sort of

s.matthew.english
2016-07-30 15:48
new phase in blockchain development

s.matthew.english
2016-07-30 15:48
"consortial model"

cbf
2016-07-30 15:48
you can run the node app: node app.js

cbf
2016-07-30 15:49

s.matthew.english
2016-07-30 15:49
I was following the docs from here

s.matthew.english
2016-07-30 15:49

s.matthew.english
2016-07-30 15:49
yeah I've run fabric locally before

s.matthew.english
2016-07-30 15:49
one of the IBM guys helped me

s.matthew.english
2016-07-30 15:49
in this slack channel

s.matthew.english
2016-07-30 15:50
I wrote some crap on my blog about it

s.matthew.english
2016-07-30 15:50

s.matthew.english
2016-07-30 15:50
wait

s.matthew.english
2016-07-30 15:50
not that lin

s.matthew.english
2016-07-30 15:50
link


s.matthew.english
2016-07-30 15:51
that one

cbf
2016-07-30 15:51

cbf
2016-07-30 15:51
install and configure that

s.matthew.english
2016-07-30 15:51
ok cool

s.matthew.english
2016-07-30 15:51
I'll go do that

s.matthew.english
2016-07-30 15:51
and maybe

s.matthew.english
2016-07-30 15:51
when I finish

s.matthew.english
2016-07-30 15:52
I'll ping you in here

s.matthew.english
2016-07-30 15:53
ok so

s.matthew.english
2016-07-30 15:53
it installed

s.matthew.english
2016-07-30 15:53
then I can run the marbles app?

s.matthew.english
2016-07-30 15:54
I ran 'ibm-blockchain-js' and it worked

s.matthew.english
2016-07-30 15:55
but it's sort of unclear how to proceed from there


cbf
2016-07-30 15:56
looks like the guys have been busy updating this

cbf
2016-07-30 15:56
the plan is to contribute this to hyperledger

s.matthew.english
2016-07-30 15:56
aha- ok cool

cbf
2016-07-30 15:56
LMK if you have any issues with that last link

s.matthew.english
2016-07-30 15:57
certainly will do

s.matthew.english
2016-07-30 15:57
thank you very much!

cbf
2016-07-30 15:57
yep

s.matthew.english
2016-07-30 16:58

s.matthew.english
2016-07-30 16:58

s.matthew.english
2016-07-30 16:59
@cbf it seemed to work- almost- I screenshot (above) the errors I got

s.matthew.english
2016-07-30 17:03

s.matthew.english
2016-07-30 17:05
maybe it's because I didn't do anything about 'mycreds.json'

s.matthew.english
2016-07-30 17:14
that was the error from my original 'mycreds.json' file

s.matthew.english
2016-07-30 17:14
this is the one I get when I substitute the content of 'mycreds.json' as was on the docs of https://github.com/IBM-Blockchain/marbles/blob/master/tutorial_part1.md#run-marbles-on-local-machine

s.matthew.english
2016-07-30 17:15

cbf
2016-07-30 17:30
you will need to configure the membership services yaml with those creds

cbf
2016-07-30 17:30
I think

ry
2016-07-31 00:48
If you have a pending change and the build log is missing, let me know directly. I increased build log retention from 10 builds to 30 days this morning

ry
2016-07-31 00:48
If the build log is missing and you need it :grinning:

s.matthew.english
2016-07-31 11:37
@cbf :confused: which creds do you mean? it's the `mycreds.json` that I will need to configure- isn't it? do the creds come from my machine?

cbf
2016-07-31 12:09
I believe that you need to configure the membersrvc.yaml to also include those mycreds.json values so that the users are known.

s.matthew.english
2016-07-31 12:11
ah

s.matthew.english
2016-07-31 12:11
from the sample

s.matthew.english
2016-07-31 12:12
so it should reflect { "credentials": { "peers": [ { "api_host": "http://12345678-abcde-_vp0.blockchain.ibm.com", //hostname or ip of peer "api_port_tls": 443, //https port (optional) "api_port": 80, //http port "id": "12345678-abcde-4d6f-_vp0", //unique id of peer }, ], "users": [ { "enrollId": "user_type1_1234567890", //enroll username "enrollSecret": "1234567890" //enroll's secret } ] } }

s.matthew.english
2016-07-31 12:14
I don't see a file called `membersrvc.yaml`

codascud
2016-08-01 01:15
@s.matthew.english: its under membersvc directory…. https://github.com/hyperledger/fabric/tree/master/membersrvc

bgorman
2016-08-01 01:56
@ry thanks for the heads up on the gerrit HTTP passwords

trustedblocks
2016-08-01 06:21
has joined #fabric-dev

hgabor
2016-08-01 07:02
is it possible to edit Jenkins jobs using GUI? just for debugging purposes

baohua
2016-08-01 07:34
it needs privilege.

hgabor
2016-08-01 07:36
could anybody give me such privilege?

manish-sethi
2016-08-01 08:59
@simon: regarding keeping ‘chaincode' in the state instead of in the chain - I had made some related changes in @muralisr’s branch at https://github.com/muralisrini/fabric/blob/uber_chaincode/core/chaincode/exectransaction.go#L88. This change does not include the chaincode code itself though.

s.matthew.english
2016-08-01 13:03
@codascud do you know how I would need to modify `membersrvc.yaml` and `mycreds.json` to run the marbles example on my machine?

codascud
2016-08-01 14:02
@s.matthew.english: sorry.. not sure…

hgabor
2016-08-01 14:43

muralisr
2016-08-01 14:49
@hgabor: my one big comment with that PR, seems like users coming in via SDK won’t be excercising this path at all ?

muralisr
2016-08-01 14:49
I could be wrong...

hgabor
2016-08-01 14:50
does the SDK send a TX including its ID?

muralisr
2016-08-01 14:50
I believe so but we should double check

hgabor
2016-08-01 14:51
could you comment this to there? to remind me, tomorrow I will have to check this

muralisr
2016-08-01 14:51
certainly

muralisr
2016-08-01 14:51
actually I thought I did but I don’t see it there

hgabor
2016-08-01 14:52
does the sdk use grpc?

s.matthew.english
2016-08-01 14:58
do any of you guys know how I can go about running the marbles example locally on my machine?


s.matthew.english
2016-08-01 14:58
that one

muralisr
2016-08-01 14:59
@hgabor: I believe so but we should take this to fabric-sdk and get SDK expert’s help

s.matthew.english
2016-08-01 15:00
I can get to `Server Up - localhost:3000 ` but not to `Websocket Up` I guess because I need to properly configure \ synchronize `membersrvc.yaml` & `mycreds.json` , but- does anyone know how to go about that?

hgabor
2016-08-01 15:02
@muralisr: I think I have found the sending part. for me, it seems to use plain socket. it creates a TX and it also generates an ID. I have to find out how this is handled from fabric side. In this case, if the ID is not a Bitcoin style TXID (like the one I am introducing in my commit), the TX will be impossible to be found using the SDK given ID.

hgabor
2016-08-01 15:03
So I will have to modify this part of the SDK to use content generated IDs.

hgabor
2016-08-01 15:03
what do you think?

muralisr
2016-08-01 15:11
@hgabor: possibly, I think it’d depend on how generous we’d want it to be. We probably need to cover all kinds of transactions… we’ll need to run this by @keithsmith and others.

hgabor
2016-08-01 15:13
@muralisr: please have a look at my comment in #

muralisr
2016-08-01 15:13
ok

kostas
2016-08-01 15:57
A Gerrit-related question: I need to rebase a changeset that's already been pushed to Gerrit. I believe amending a change (as described here: https://www.mediawiki.org/wiki/Gerrit/Tutorial#Amending_a_change_.28your_own_or_someone_else.27s.29) is how I should go about it. Can someone confirm? (/cc @cbf who might know)

muralisr
2016-08-01 15:58
@kostas: thanks to @cbf :

muralisr
2016-08-01 15:59
git checkout master git pull origin git checkout <your branch> git rebase master <resolve any conflicts>

muralisr
2016-08-01 15:59
I had the same question over the weekend and the above helped me

kostas
2016-08-01 16:05
@muralisr: Thank you. These are instructions on how to rebase in general though, right? (Unless I'm missing something, which I might be.) I'm wondering how the rebase should be handled in terms of an existing changeset in Gerrit.

muralisr
2016-08-01 16:05
just making sure we are on the same page… here’s what I was running into

muralisr
2016-08-01 16:06
I had changeset for review in gerritt

muralisr
2016-08-01 16:06
a day later it was flagged with merge conflicts

muralisr
2016-08-01 16:06
so I had to rebase and push on top of that same original changeset

muralisr
2016-08-01 16:06
I used the above instructions to do that

kostas
2016-08-01 16:27
@muralisr: My situation is the same. Looks like no special treatment is necessary then. Thanks!

ry
2016-08-01 16:35
kostas: as long as you use the same change ids Gerrit should stitch it up nicely

kostas
2016-08-01 17:15
Gotcha.

jonathanlevi
2016-08-01 18:18
A quick heads-up: Chris Ferris' change which reassigned ports in Fabric has been merged and we all need to rebuild our dev-environments.


grapebaba
2016-08-02 00:42
@cbf: @muralisr @kostas now it have several documents describe the submit amend rebase changes, but not quite consistence

grapebaba
2016-08-02 00:42
could you make a standard guide for this include both use git review or not

bgorman
2016-08-02 05:21
I have a changeset (https://gerrit.hyperledger.org/r/#/c/365/) to let unittesting be done on chaincode with a nice interface.... problem is the Jenkins build fails because I've changed the interface and the build relies on artifacts outside of hyperledger/fabric that I can't easily update

bgorman
2016-08-02 05:22
does anyone have any suggestions about what I should do? I can't "fix" Jenkins within a Gerrit review because of the outside dependencies... I also don't think it's a good idea to remove the tests that fail

matpasha
2016-08-02 07:17
has joined #fabric-dev

s.matthew.english
2016-08-02 09:26
does anyone perhaps have an idea on how to proceed with the problem detailed in this GitHub issue: https://github.com/IBM-Blockchain/marbles/issues/27#issuecomment-236617204

s.matthew.english
2016-08-02 09:26
I'm running into problems trying to run the marbles demo locally on my own machine

kenhuangus
2016-08-02 18:32
has joined #fabric-dev

lisacheng
2016-08-02 19:49
has joined #fabric-dev

sunsay00
2016-08-02 20:09
Hi, I am new to hyperledger and i am trying to play around with the examples in Windows 7. When i try register the example, i get 'CORE_CHAINCODE_ID_NAME' is not recognized as an internal or external command, operable program or batch file. Anyone know what I'm missing?

sunsay00
2016-08-02 23:00
NV. I figured it out. I have to run the command like "chaincode_example02 CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=0.0.0.0:30303", but now i'm getting "peer.address not configured, can't connect to peer"

jcarrivick
2016-08-03 00:12
@sunsay00: `CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=0.0.0.0:30303` should come before the command as they are setting the environment variables for the command to use

jcarrivick
2016-08-03 00:15
Frustratingly often after pulling in latest changes from master or checking out another branch, building the peer and running it I get a panic: ``` vagrant@hyperledger-devenv:v0.0.10-41c75fe:/hyperledger$ peer node start panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0x4ad061] goroutine 1 [running]: panic(0xd731e0, 0xc82000e110) /opt/go/src/runtime/panic.go:464 +0x3e6 http://github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x155be80, 0x1599288, 0x0, 0x0, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:479 +0x521 http://github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x155c580, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:584 +0x46a main.main() /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:122 +0xa3a ``` Does anyone know how to fix it short of rebuilding my entire vagrant environment? Because that's the only way I've managed to fix it in the past.

ghaskins
2016-08-03 00:16
i think “make dist-clean” should scrub the environment

ghaskins
2016-08-03 00:16
hmm, that doesnt remove the pkg though

ghaskins
2016-08-03 00:16
that should probably be fixed...

ghaskins
2016-08-03 00:17
but you can do it by hand: rm -rf $GOPATH/pkg

jcarrivick
2016-08-03 00:18
@ghaskins: Ah so it's using old compiled files maybe

ghaskins
2016-08-03 00:18
thats my guess

jcarrivick
2016-08-03 00:19
Cool, I just `make dist-clean` before you said that so we'll see if it still doesn't work after it's finished rebuilding

ghaskins
2016-08-03 00:19
the build is _supposed_ to be detecting when .go files have changed and recompiling them, but not sure how well that extends out to $GOPATH/pkg

ghaskins
2016-08-03 00:19
im just speculating anyway

jcarrivick
2016-08-03 00:19
right, OK, that would make sense

ghaskins
2016-08-03 00:19
but in theory: "make dist-clean && rm -rf $GOPATH/pkg” should effectively start you over

jcarrivick
2016-08-03 00:19
I'll do some experimenting once everything is set up again

ghaskins
2016-08-03 00:20
(without rebuilding the vagrant image)

ghaskins
2016-08-03 00:20
have to get kids to bed, bbiab

jcarrivick
2016-08-03 00:21
sure thing

jcarrivick
2016-08-03 00:22
Should I create a change to `dist-clean` to `rm-rf $GOPATH/pkg`?

jcarrivick
2016-08-03 00:33
Interestingly, that hasn't worked. `make dist-clean && rm -rf $GOPATH/pkg` followed by `make peer` still exhibits the problem :confused:

jcarrivick
2016-08-03 00:34
I'll do some more digging, maybe Go stores some files elsewhere as well...

jcarrivick
2016-08-03 01:27
weird, it has decided to start working again. On a hunch I updated the cobra library and it worked! But then I put it back to the old version and it is still working :S

jcarrivick
2016-08-03 01:27
I guess I'll wait until it happens again before I can do more investigation

jcarrivick
2016-08-03 03:15
OK I figured out what was going on for anyone interested

jcarrivick
2016-08-03 03:17
In the version of cobra we have in the vendor folder, if there is a PersistentPreRunE it expects a corresponding PersistentPostRunE too. When it doesn't exist, it panics.

jcarrivick
2016-08-03 03:17
Updating the Cobra library fixes it, but also adding an empty PersistentPostRunE function also is a workaround

grapebaba
2016-08-03 03:52
yes @jcarrivick i met this issue when i add version command

jcarrivick
2016-08-03 03:55
@grapebaba: :thumbsup: I have submitted a patch now to update the vendor copy of cobra so hopefully we won't need to have the empty PersistentPostRunE any more!

adamrichard
2016-08-03 06:24
has joined #fabric-dev

maheshpatil13
2016-08-03 06:52
has joined #fabric-dev

hgabor
2016-08-03 09:36
could anybody help me? I have a failing Jenkins test: https://jenkins.hyperledger.org/job/fabric-verify-x86_64/154/console It works on my laptop. (commit: https://gerrit.hyperledger.org/r/#/c/317/) How could I debug it?

hgabor
2016-08-03 12:09
for Zsolt, it works too

baohua
2016-08-03 14:05
Sent a recheck for u. last time i met this msg, it was jenkins failure.

hgabor
2016-08-03 15:40
thanks :slightly_smiling_face:

louisw
2016-08-03 16:55
has joined #fabric-dev

binhn
2016-08-03 17:20
@ry: hi Ry, do you know how we should handle the Fabric wiki in Gerrit?

ry
2016-08-03 19:02
@binhn: I do not know the plans.

ghaskins
2016-08-03 19:32
@simon: Are you firm in your -2 on https://gerrit.hyperledger.org/r/#/c/319 ?

ghaskins
2016-08-03 19:32
Lack of events is really hurting the project for things like closing the feedback loop in SDK clients, would be nice to get something in sooner rather than later

simon
2016-08-04 09:36
well, do we review to get good code quality, or do we review so that people don't vandalize?

ghaskins
2016-08-04 12:06
vandalize? could you be more constructive please?

simon
2016-08-04 12:06
well, i'm trying to understand the purpose of the reviews

ghaskins
2016-08-04 12:07
afaict, you made some comments which were addressed, and you made another comment about why it wasnt split into two patches and that was responded to

simon
2016-08-04 12:07
i did not see that reply

ghaskins
2016-08-04 12:07
its possibly a flaw in the gerrit flow, as I think they were inline comments that get hidden once the code is changed

ghaskins
2016-08-04 12:07
but I saw them go by

ghaskins
2016-08-04 12:08
ill see if I can find them in the UI

simon
2016-08-04 12:08
yea, that is very unfortunate that the comments don't carry over

simon
2016-08-04 12:10
https://gerrit.hyperledger.org/r/#/c/319/10/events/producer/handler.go introduces `getInterestKey`, which open codes some ad-hoc serialization to use it as a map key

simon
2016-08-04 12:11
i don't think this is good code practice, and I've not heard anything about this

simon
2016-08-04 12:11
also i don't understand why the non-async case receives the timeout in the constructor

simon
2016-08-04 12:12
why set a timeout, why allow custom timeout, why in the constructor, why not use a context

ghaskins
2016-08-04 12:12
That part I know was answered here


ghaskins
2016-08-04 12:13
as far as getInterestKey, thats fine that you object, but I don’t know if its clear to the author what remains to get a +2 from you

ghaskins
2016-08-04 12:13
(its possibly a gerrit flaw)

ghaskins
2016-08-04 12:13
as I know you mentioned it prior

simon
2016-08-04 12:14
yea i think it is becoming clear that communication exclusively via gerrit doesn't work

ghaskins
2016-08-04 12:15
I think the question about sync+async in one patch was answered in that same changeset

simon
2016-08-04 12:15
i don't understand the timeout API reply. if we change the constructor, the API changes. might as well change the register/unregister API?

ghaskins
2016-08-04 12:15
I dont know the context, its a fair enough question

simon
2016-08-04 12:16
doesn't feel right to set the timeout there

simon
2016-08-04 12:16
i think go idiomatic would be to pass a context to the function that does the operation

simon
2016-08-04 12:16
but i wonder why it is even necessary to have a timeout in the first place

simon
2016-08-04 12:17
how would the caller deal with such a timeout?

simon
2016-08-04 12:17
retry?

simon
2016-08-04 12:17
we have plenty of rpc operations, and none of them take timeouts

ghaskins
2016-08-04 12:18
my take it was part of auto unregistration policy, therefore its not in the same category as a normal RPC response type thing

simon
2016-08-04 12:18
i didn't see any auto unregister?

ghaskins
2016-08-04 12:19
oh, i see what you are saying

ghaskins
2016-08-04 12:19
its literally a timeout for the RPC, not the event registration

ghaskins
2016-08-04 12:20
i think that Pat answered that though:

ghaskins
2016-08-04 12:20
there always was a timeout, it was just hardcoded

simon
2016-08-04 12:21
right, so what's our policy then

simon
2016-08-04 12:21
keep questionable code when we touch it?

simon
2016-08-04 12:21
or fix up code when we touch it

ghaskins
2016-08-04 12:21
no, i think you are right to call that out

ghaskins
2016-08-04 12:22
i think its also not clear what the action items are because of the way gerrit seems to work

simon
2016-08-04 12:22
yes, i agree

simon
2016-08-04 12:23
so my take is:

simon
2016-08-04 12:23
no timeout

ghaskins
2016-08-04 12:23
can you do me a favor and just go through the latest with any remaining objections so they are clear

ghaskins
2016-08-04 12:23
i will back you on the questioning of whether that timeout should remain

simon
2016-08-04 12:24
is patrick on slack?

simon
2016-08-04 12:24
it would be so much easier to talk about this here

ghaskins
2016-08-04 12:24
yes, @pmullaney

ghaskins
2016-08-04 12:24
not sure he is online yet though

simon
2016-08-04 12:24
okay

simon
2016-08-04 12:24
i think all this timeout business should go away

simon
2016-08-04 12:24
instead expose access to the context of the grpc connection

simon
2016-08-04 12:25
and this sync registration code is broken anyways

simon
2016-08-04 12:26
if you call sync registration, and the other side is slow, and you abort

simon
2016-08-04 12:26
ah no

simon
2016-08-04 12:26
it's even worse

simon
2016-08-04 12:27
say you're already registered to something

simon
2016-08-04 12:27
and you do another register

simon
2016-08-04 12:27
then it will report an error if there is a different message arriving

simon
2016-08-04 12:27
and that even will be lost, no?

simon
2016-08-04 12:27
yes

simon
2016-08-04 12:27
that whole code needs rework

simon
2016-08-04 12:28
that's why i think that we should start with an empty repo

simon
2016-08-04 12:28
and copy over pieces that get reviewed

simon
2016-08-04 12:28
alternatively, i could go over all the code that we have and review it

simon
2016-08-04 12:28
and then we go and address issues

simon
2016-08-04 12:29
before adding new features

yacovm
2016-08-04 13:07
Hey, does anyone know if I can authenticate to Gerrit via my github id (some kind of SSO)?

yacovm
2016-08-04 13:08
I'm currently logged into github and when I go to the gerrit page it doesn't "detect" the SSO

simon
2016-08-04 13:10
yea it doesn't

simon
2016-08-04 13:10
you need to use your linuxfoundation ID

yacovm
2016-08-04 13:10
oh but I was hoping to use my github ID as my LF id...

simon
2016-08-04 13:11
yea well

simon
2016-08-04 13:11
doesn't seem to work

simon
2016-08-04 13:11
you can register with your gh id

simon
2016-08-04 13:12
but then you still need to set a password to log in to gerrit

yacovm
2016-08-04 13:13
that's what I'm doing, thanks

simon
2016-08-04 13:15
you will have to log out from linuxfoundation identity

simon
2016-08-04 13:15
so that you can reset your password

ghaskins
2016-08-04 13:17
It might work if you go the other way

ghaskins
2016-08-04 13:17
Create LFID and then attach an SSO to it

ghaskins
2016-08-04 13:18
It def does -not- work to do it SSO first

yacovm
2016-08-04 13:21
thanks simon & ghaskins, I think I'll learn to live with it(the LF id, that is)

pmullaney
2016-08-04 15:01
@ghaskins: I am on now

simon
2016-08-04 15:02
hi patrick

pmullaney
2016-08-04 15:03
hi simon

simon
2016-08-04 15:08
@pmullaney: see above for some feedback on the events patch and the code in general

pmullaney
2016-08-04 15:10
so we might want to bring @muralisr into the discussion too

pmullaney
2016-08-04 15:11
basically I have tried to scope the changes to maintain the existing API for fear of A) breaking clients B) limit impact in general

pmullaney
2016-08-04 15:12
I would have broken the patch into just the unreg addition and then the consumer changes however there was no way currently to test the unreg addition with changes on the consumer side

pmullaney
2016-08-04 15:13
and there was a requirement to test the additions

pmullaney
2016-08-04 15:14
as far as the timeout, the change I performed was a result of @muralisr pointing out the hardcoded value during a previous PR review - note I had not touched that originally - so in an effort to improve I moved it to the comsumers context

pmullaney
2016-08-04 15:14
and made it variable

pmullaney
2016-08-04 15:16
so worth pointing out and this is just my opinion, I don't see consumer as being something that clients often use - I am working on sdk additions that should be how clients interact

pmullaney
2016-08-04 15:18
in other words, consumer.go is test enabling and example code on how to deal with the underlying protobufs api

pmullaney
2016-08-04 15:27
I think your comments may have more to do with the code in general not the additions - for that I would suggest the following, add the unregister to the current api(with or without the consumer changes - note that without there will be no unit testing of the unregister - or with minor changes to timeout as you suggest) - review the entire component starting with the protobufs api, decide on rewrite or incremental improvement

ghaskins
2016-08-04 15:34
Could one of the other maintainers take a look at https://gerrit.hyperledger.org/r/#/c/357. Has 1+2, needs 2+2, but otherwise ready for merge

muralisr
2016-08-04 15:35
@simon, @pmullaney : the there are two ways to view the timeout : one as a global property for the session and another as a per invoke parameter

muralisr
2016-08-04 15:35
the current implementation takes the former view so all register/unregister will use the same timeout value

muralisr
2016-08-04 15:36
this is consistent with other uses of timeout in the fabric (except we don’t store the property in a yaml file)

lbonniot
2016-08-04 15:38
@ghaskins: +1 I'm kind of stuck waiting for this patch to be merged :wink: @pmullaney: what's the purpose of consumer.go if it won't be used by clients? It's only imported in one test and one example right now. I think clients should be encouraged to use this package, or there should be a deprecation notice somewhere. It would be more efficient for client developers like me :wink:

muralisr
2016-08-04 15:38
Originally, the registratio was a one time call at the time of setting up the client and the timeout will result in a failure to setup

pmullaney
2016-08-04 15:38
and we certainly can store it in a yaml file but one does not exist for the consumer to date

muralisr
2016-08-04 15:38
right

ghaskins
2016-08-04 15:39
@lbonniot: I don’t want to speak for @pmullaney, but I took what he said to mean “clients wont use it directly, because its abstracted behind the SDK"

muralisr
2016-08-04 15:40
as opposed to core.yaml etc, the code is directly called by client… I only mentioned the yaml to draw some lines to other fabric code

muralisr
2016-08-04 15:40
it is not true that if there’s a timeout the client cannot do anything

pmullaney
2016-08-04 15:40
@ibonniot: I am fine with clients using it. Just note, that the sdk will have an api, initially node, that will support this

pmullaney
2016-08-04 15:41
eventually, if a go sdk is developed, the client should move there

pmullaney
2016-08-04 15:41
the other option for client developers is to use protobufs directly

muralisr
2016-08-04 15:42
indeed, to @pmullaney’s point, block-listener.go uses consumer directly

ghaskins
2016-08-04 15:42
@muralisr: could you chime in on this: https://gerrit.hyperledger.org/r/#/c/399/ ?

muralisr
2016-08-04 15:43
@ghaskins: let me look

pmullaney
2016-08-04 15:44
to @muralisr point on timeout and clients not being able to do anything, I second his opinion client could and should retry

lbonniot
2016-08-04 15:48
Thanks for the info. I'm using grpc to communicate with the event hub right now, but the final code looks like consumer.go. I did not want to use it because of the lack of live register/unregister, but your patch seems to be pretty interesting. However, just to say, passing a context is really better than a raw duration. Contexts can be cancelled in many ways, store the final deadline and are more idiomatic :wink:

simon
2016-08-04 15:48
i still don't get the timeout thing

simon
2016-08-04 15:48
why is there a timeout, and what does it mean for the timeout to expire?

simon
2016-08-04 15:49
how do you deal with an expired timeout

simon
2016-08-04 15:49
why not use the grpc/stream context?

lbonniot
2016-08-04 16:02
After reading the code, I agree with @simon ; it should not be merged as this. There should only be one `ec.stream.Recv()` call in the consumer to avoid concurrent issues. If the current version is merged, it will break someone's code in a very random way one day; and nobody likes that - especially if this part of the code is supposed to be integrated in some SDKs. Calling `Start` before any additional `(Un)Register` would solve the problem. When encountering (un)register events, the `Start` loop would send this event to a local channel, and voilà. Adding a context argument in `(Un)Register` functions would be perfect to avoid blocking indefinitely one client.

pmullaney
2016-08-04 16:05
@ibonniot: I know what you are getting at and contemplated fixing it but that would have broken current clients

lbonniot
2016-08-04 16:12
@pmullaney: Hm from what I'm seeing, the `Start` and `Stop` functions would not have been modified, so no breaking change? There is a breaking change anyway in the current patch (new argument in `NewEventsClient`)... Maybe I'm wrong :confused: Anyway I'm not a maintainer, just giving some feedbacks from an event consumer user :wink:

pmullaney
2016-08-04 16:13
the problem arises because we are trying to support a more dynamic model of registration and the original model is static in that you register all your interests at connection creation

pmullaney
2016-08-04 16:14
its good feedback

pmullaney
2016-08-04 16:15
there is a breaking change but it was somewhat limited as opposed to touching every reg/unreg

pmullaney
2016-08-04 16:17
so with limited changes in mind, one possbility is to fail calls to the sync api if the consumer has called the processEvents loop

pmullaney
2016-08-04 16:18
this would introduced another breaking change in that the client would have to manually enter the loop

pmullaney
2016-08-04 16:18
this is how I originally coded it actually but then got concerned via discussions that it break existing clients

pmullaney
2016-08-04 16:20
I assume this is the random breaking that you were referring too

pmullaney
2016-08-04 16:21
oh on the start and stop, yea I looked at that as well, unfortunately I was not able to find a clean solution to breaking out of the recv call deep in the protobufs code

pmullaney
2016-08-04 16:23
another option for us would be the following, create 2 clients - one that supports the old model and one that support the new

lbonniot
2016-08-04 16:24
There is (maybe) a way to not break everything I think. - Disable (Un)Register(Async) calls as long as the connection is not established (i.e. not Started) - In Start call, the consumer first starts the loop and then calls the Register function from EventAdapter definition (so Start will block until everything is registered) - There would be a channel communication between the main loop and (Un)Register functions. This communication would be quite tricky however, because Register events may come unordered... A mutex on (Un)Register(Async) could solve that, depends on the wanted level of parallelism.

jonathanlevi
2016-08-04 16:25
I believe it's totally fine to have a mutex in `UnrRegisterAsync`

jonathanlevi
2016-08-04 16:25
FWIW

pmullaney
2016-08-04 16:26
I don't follow - why disable the async?

lbonniot
2016-08-04 16:27
just an idea to cope with the communication between main loop and (un)register functions, it would depend how it's done I guess

pmullaney
2016-08-04 16:28
if your not in the mainloop, one *can* call the Recv if interested in the reply

lbonniot
2016-08-04 16:28
yeah... but theoretically, you'll be in the main loop when calling (Un)Register functions... Right?

pmullaney
2016-08-04 16:28
so if we want parrallism, you would not have a mainloop

lbonniot
2016-08-04 16:29
that's also a possibility

pmullaney
2016-08-04 16:29
you would create your own with Recv

pmullaney
2016-08-04 16:29
per cpu or something like that

pmullaney
2016-08-04 16:31
so in short, I think we need to agree on something incremental and address what we want in the sdk context

pmullaney
2016-08-04 16:32
consumer.go is a thin wrapper around protobufs at the moment

pmullaney
2016-08-04 16:36
if we want I can put together a second client that will just expose the necessary calls for clients to process their own events(without a mainloop)

pmullaney
2016-08-04 16:40
in addition for this patchset, I think I can just change the sync forms of the register/unregister to not be accessible to clients

pmullaney
2016-08-04 16:41
actually this seems like the best short term option, will take a closer look

pmullaney
2016-08-04 16:51
@ibonniot: making the sync forms of reg/unreg looks like it will maintain the current functionality which addresses your concern about synchronization - this is a simple and nonbreaking change which I like in the short term, then we can address a new client

pmullaney
2016-08-04 16:52
then clients can migrate when they want

muralisr
2016-08-04 16:57
@pmullaney: @lbonniot : the grpc stream Send is the only thing that needs to be serialized I think. If we pull the Send out into a separate function and protect it with a lock, we can call that function wherever Send is used and should be safe

muralisr
2016-08-04 17:52
so basically couple of things (1) don’t expose register for external use so we don’t allow concurrent Recvs and (2) protoct grpc stream Send with a lock

pmullaney
2016-08-04 18:43
I just uploaded the proposed changes as patchset 11 in https://gerrit.hyperledger.org/r/#/c/319/

jcarrivick
2016-08-05 01:57
I'm trying to perform REST queries against the `membersrvc` and it seems that no matter what I do I get mangled text back (`��`) and the log says bogus greeting: `2016/08/05 01:51:47 transport: http2Server.HandleStreams received bogus greeting from client: "GET /registrar/test_vp0 "`. I assume that I am required to log in some how but I cannot seem to figure out how. Is someone able to point me in the right direction/documentation please?

ghaskins
2016-08-05 02:41
@jcarrivick: it sounds like you are hitting the GRPC HTTP/2 port

jcarrivick
2016-08-05 02:43
Ahh that would make a lot of sense. Does that mean I require peer to be up to interact with the membersrvc?

ghaskins
2016-08-05 02:43
note that HTTP/2 is binary and the GRPC interface is not conducive to curl-like strategies even if you found an HTTP/2 compatible clinet

jcarrivick
2016-08-05 02:43
via rest that is

ghaskins
2016-08-05 02:43
im not sure tbh

ghaskins
2016-08-05 02:43
ive never tried to talk to the CA via rest

ghaskins
2016-08-05 02:44
only indirectly via the peer and/or SDK

jcarrivick
2016-08-05 02:44
I was attempting to use the `/registrar` endpoint

ghaskins
2016-08-05 02:44
but I do have some experience with trying to curl a GRPC endpoint, and the behavior you mention looks familar :wink:

jcarrivick
2016-08-05 02:44
Thanks, yeah that was helpful :slightly_smiling_face:

ghaskins
2016-08-05 02:45
i suspect you have the wrong port

ghaskins
2016-08-05 02:45
can you netstat the running process and see if there is a second option?

jcarrivick
2016-08-05 02:45
yep, I'll do it now

jcarrivick
2016-08-05 02:47
`tcp6 0 0 :::7054 :::* LISTEN 11531/membersrvc`

jcarrivick
2016-08-05 02:47
looks like that's the only port, so we have to use the peers to interact with it via rest

jcarrivick
2016-08-05 02:48
strange that it's only ipv6

ghaskins
2016-08-05 02:48
something doesnt smell right

ghaskins
2016-08-05 02:48
there should at least be one tcp4

jcarrivick
2016-08-05 02:49
I'm just running the membersrvc directly in vagrant, not in docker if that makes a difference

ghaskins
2016-08-05 02:49
it shouldnt

ghaskins
2016-08-05 02:49
let me look at my setup, hold on

ghaskins
2016-08-05 02:50
thats weird, thats all I see too

ghaskins
2016-08-05 02:50
im confused

jcarrivick
2016-08-05 02:50
Yet I still get a response on ipv4

jcarrivick
2016-08-05 02:50
It couldn't be a HTTP/2 thing could it?

ghaskins
2016-08-05 02:50
not that I am aware of

grapebaba
2016-08-05 05:35
rest only against with peer

grapebaba
2016-08-05 05:36
membersrvc only expose grpc

ramesh
2016-08-06 01:46
Hi all, I have configured `go unit-test code coverage report` in Jenkins CI. Here is the reference link.. https://jenkins.hyperledger.org/job/fabric-merge-x86_64/8/cobertura/

alexho
2016-08-07 15:49
has joined #fabric-dev

hgabor
2016-08-08 08:19
Hi all. I have this error: https://jenkins.hyperledger.org/job/fabric-verify-x86_64/216/console Locally, it works: I deleted and recreated vagrant so it definitely works in a new environment. Can anybody help how could I get the logs from Jenkins? I need docker container logs.

simon
2016-08-08 08:20
is it maybe a timing thing?

simon
2016-08-08 09:16
@ry, @ramesh: can we set up gerrit so that jenkins verifies the code how it would be if the changeset was accepted?

simon
2016-08-08 09:17
i.e. if it requires rebase/merge, check the result of that, and not the branch by itself?

hgabor
2016-08-08 09:32
there is a post-merge build/verification I think

hgabor
2016-08-08 09:35
could somebody check this ASAP https://gerrit.hyperledger.org/r/#/c/453/

ry
2016-08-08 12:22
@simon: possibly, but is better if the change is re based by the author

simon
2016-08-08 12:23
i see

simon
2016-08-08 12:24
ry: the problem is that if we do merges, we may inadvertently introduce bugs

ry
2016-08-08 12:25
simon: I don’t quite understand what you mean. the merge happens at some point, regardless, right?

simon
2016-08-08 12:40
ry: correct. but if jenkins verifies the state before the merge, then the merge might introduce problems, and we only find out later

ry
2016-08-08 12:47
simon: one way to enforce this would be to require fast-forward only submissions, but it would mean after every merge every pending change would need to be rebased.

simon
2016-08-08 12:47
:confused:

simon
2016-08-08 12:48
maybe we could have a bot that automatically merges/rebases (depending on submission) the patch sets as soon as master changes?

ry
2016-08-08 12:48
when we were discussing github->gerrit, I brought it up as an option but I do not recommend it. The last time I used it, it was abandoned within a week.

simon
2016-08-08 12:48
but i guess we can do that manually for now

simon
2016-08-08 12:52
how do we restart jenkins in case it failed for unclear reasons?

ry
2016-08-08 12:52
if you log in to Jenkins, then look at a build, you should have a “retrigger” button on the left.

simon
2016-08-08 12:55
ah thanks

ry
2016-08-08 12:58
@simon: for instance, if you are logged in and go to https://jenkins.hyperledger.org/job/fabric-verify-x86_64/222/ , right now it has a retrigger button (but if someone retriggers it, that button goes away)

ry
2016-08-08 12:59
@ry uploaded a file: https://hyperledgerproject.slack.com/files/ry/F1Z71S1FX/screen_shot_2016-08-08_at_5.58.21_am.png and commented: if you don’t see it and you are logged in, let me know directly


cbf
2016-08-08 16:33
proposal for migration to Jira

cbf
2016-08-08 16:33
please pile on in email

simon
2016-08-08 16:34
+1

simon
2016-08-08 16:34
fresh start is good

cbf
2016-08-08 16:34
agree

arnaud
2016-08-08 16:43
Definitely.

cbf
2016-08-08 18:59
@ghaskins: is on holiday, would like to hear from @binhn @tamas

cbf
2016-08-08 18:59
@hgabor and @jonathanlevi

cbf
2016-08-08 18:59
if we all agree, let’s implement

hgabor
2016-08-08 19:07
I agree and Tamas is on holiday. I will also respond to the mailing list

jcarrivick
2016-08-09 01:14
Hi guys, I have a test case for https://gerrit.hyperledger.org/r/#/c/447/ that is failing on Jenkins (https://jenkins.hyperledger.org/job/fabric-verify-x86_64/228/) but I can't replicate on my local machine. It seems to be a problem with the docker networking because each of the peers don't seems to be able to connect to each other once they're brought back up. The following log snippet seems to show the problem and is replicated across the peers: ``` 16:47:05.762 [consensus/pbft] recvViewChange -> WARN 160 Replica 2 already has a view change message for view 2 from replica 0 2016/08/08 16:47:06 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 172.17.0.86:7051: getsockopt: no route to host"; Reconnecting to "172.17.0.86:7051" 2016/08/08 16:47:06 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 172.17.0.87:7051: getsockopt: no route to host"; Reconnecting to "172.17.0.87:7051" 16:47:06.441 [peer] chatWithPeer -> ERRO 161 Error creating connection to peer address 172.17.0.87:7051: grpc: timed out trying to connect 16:47:06.442 [peer] chatWithPeer -> ERRO 162 Error creating connection to peer address 172.17.0.86:7051: grpc: timed out trying to connect 16:47:07.628 [consensus/util/events] loop -> DEBU 163 Event timer fired 16:47:07.628 [consensus/util/events] loop -> DEBU 164 Timer event delivered 16:47:07.628 [consensus/pbft] ProcessEvent -> DEBU 165 Replica 2 batch main thread looping 16:47:07.628 [consensus/pbft] ProcessEvent -> DEBU 166 Replica 2 processing event 16:47:07.628 [consensus/pbft] ProcessEvent -> DEBU 167 Replica 2 view change resend timer expired before view change quorum was reached, resending ```

jcarrivick
2016-08-09 01:15
Would anyone have any ideas/pointers for me? I don't really know this part of the code that well.

zuowang
2016-08-09 01:15
Is it possible to invoke another chaincode when query a chaincode?

jcarrivick
2016-08-09 01:16
I believe you should be able to do both at the same time, yes.

zuowang
2016-08-09 01:19
dose that means I can call stub.InvokeChaincode when Quey a chaincode? Thanks!

jcarrivick
2016-08-09 01:21
ah, sorry, I misinterpreted that. I thought you meant call invoke and query at the same time via rest.

jcarrivick
2016-08-09 01:21
I know that a query is not allowed to modify the state of the ledger

jcarrivick
2016-08-09 01:22
but I am unsure if that determines whether it can call other invokes

muralisr
2016-08-09 01:30
query should not allow chaincode Invoke ...

hgabor
2016-08-09 07:47

hgabor
2016-08-09 10:41
@jonathanlevi said that the licenses might be problematic

satheesh
2016-08-09 14:16


troyronda
2016-08-09 15:34
has joined #fabric-dev

hgabor
2016-08-09 15:47
@satheesh: that seems to be long :slightly_smiling_face: I will have a look at it tomorrow (6PM here)

satheesh
2016-08-09 15:48
Thanks @hgabor

hgabor
2016-08-09 15:51
everyone: I have a very interesting problem with Jenkins?/testing?/...? https://gerrit.hyperledger.org/r/#/c/317/ patchset 12: locally, all the tests are OK, on Jenkins ChaincodeInvokesChaincode fails, seems to be a problem with the hardcoded chaincode id (hash) in example04 patchset 15: I changed the ID to the one I saw in the Jenkins logs. the ChaincodeInvokes... test works OK on Jenkins, but locally, it fails So the hash of example02 that is called by example04 (that is why example04 contains the hash of it) seems to be different on my machine and on Jenkins??? How?

muralisr
2016-08-09 15:59
@hgabor: can we get the chaincode folder from jenkins and compare it with yours ?

hgabor
2016-08-09 16:00
the workspace is deleted after the tests, but somehow we may hack it

hgabor
2016-08-09 16:00
@ry: do you have any idea how to do it easily?

hgabor
2016-08-09 16:01
e.g. without making a change to JJB which would keep all the workspaces or something ugly

ry
2016-08-09 16:02
hgabor: not off the top of my head. if we keep the builder alive, the next build to come along will wipe out the workspace

ry
2016-08-09 16:02
I asked for a Jenkins sandbox to be provisioned, I’m hoping it’s ready to go this week

hgabor
2016-08-09 16:09
couldnt we keep the workspaces for some builds?

hgabor
2016-08-09 16:10
or I could add some hack to my changeset which copies the directory from the workspace to some place we can store it temporarily and have a look at it

hgabor
2016-08-09 16:10
but we need such a temporary location

ry
2016-08-09 16:12
I don’t think workspaces work like that - perhaps there is a knob in JJB I don’t know about

hgabor
2016-08-09 16:15
I am sure that in jenkins you can keep the ws

hgabor
2016-08-09 16:16
wipe-workspace: false # keep the workspace...

hgabor
2016-08-09 16:16
should I set this for a while and then revert?

jonathanlevi
2016-08-09 16:17
My 2 cents: we might be able to store either a certain number of builds....

jonathanlevi
2016-08-09 16:17
... or for a number of days.

hgabor
2016-08-09 16:18
@muralisr: what could we do if we had that directory?

hgabor
2016-08-09 16:18
okay then, I will create a commit in 10minutes

ry
2016-08-09 16:18
that directory is per-slave

ry
2016-08-09 16:18
we reap the slaves every 60 seconds or so

jonathanlevi
2016-08-09 16:19

jonathanlevi
2016-08-09 16:19
(rather than that boolean-only flag)

hgabor
2016-08-09 16:20
@jonathanlevi: that keeps it for some days, that would be cool, but if the slaves are automatically wiped then no way

jonathanlevi
2016-08-09 16:20
We might also think of a process/archive step manually if needed (from within the slave)

muralisr
2016-08-09 16:20
we will just do a diff and see why two things compute different hash

muralisr
2016-08-09 16:20
if we are lucky we’ll find a difference

hgabor
2016-08-09 16:20
@jonathanlevi: that was my other suggestion, copy it to some other location. but what location are we able to access from the outside? :slightly_smiling_face:

jonathanlevi
2016-08-09 16:21
For reading or for writing (as a slave?)

hgabor
2016-08-09 16:21
@ry do you have access to the 'Edit job' menu in Jenkins? :smile:

jonathanlevi
2016-08-09 16:22
We can probably work something out, generate certificates, and SCP things over... (again, just an angle/thought)

jonathanlevi
2016-08-09 16:24
Read access from the outside (to a server) is probably less of a problem. We can also agree on a convention for the stored location (e.g., arch/build#/...)

hgabor
2016-08-09 16:24
@ry can we scp it?

ericmvaughn
2016-08-09 16:26
has joined #fabric-dev

hgabor
2016-08-09 16:27
@jonathanlevi: for me any of these solutions would be OK :slightly_smiling_face:

ry
2016-08-09 16:28
what is it you are trying to do

ry
2016-08-09 16:28
what, exactly, is the problem - not the proposed solutions

hgabor
2016-08-09 16:28
we are trying to archive the core/chaincode directory from the build as it is on the build server

hgabor
2016-08-09 16:29
we have to see how it looks because we have a clue that somehow there are modifications in it that were unintentional

ry
2016-08-09 16:34
which one?


hgabor
2016-08-09 16:35
@muralisr: I guess we need the core/chaincode and the examples

hgabor
2016-08-09 16:35
FABRIC/core/chaincode FABRIC/examples

hgabor
2016-08-09 16:35
these

ry
2016-08-09 16:36
so /w/workspace/fabric-verify-x86_64/gopath/src/github.com/hyperledger/fabric/core/chaincode /w/workspace/fabric-verify-x86_64/gopath/src/github.com/hyperledger/fabric/examples ?

hgabor
2016-08-09 16:36
yes

hgabor
2016-08-09 16:36
@muralisr: do we need anything else?

hgabor
2016-08-09 16:41
lets assume that is enough

muralisr
2016-08-09 16:59
that’s should be all


hgabor
2016-08-09 19:11
I made a diff for patchset 12 and there was no difference

hgabor
2016-08-09 19:11
please somebody else try it

hgabor
2016-08-09 19:13
I think this indicates that there is an error in the tests or in the Jenkins jobs

hgabor
2016-08-10 08:26
still struggling with that error... does anybody have any idea?

bgorman
2016-08-10 08:35
@hgabor do you mean this error? I've been getting similar in my local environment, it's been causing me some concern because I thought I broke something 18:16:51 --- FAIL: TestChaincodeInvokeChaincode (22.65s) 18:16:51 db_test_exports.go:47: Creating testDB 18:16:51 exectransaction_test.go:886: Error invoking

hgabor
2016-08-10 08:37
yes I mean that. but please read this: >hgabor 5:51 PM everyone: I have a very interesting problem with Jenkins?/testing?/...? >https://gerrit.hyperledger.org/r/#/c/317/ >patchset 12: locally, all the tests are OK, on Jenkins ChaincodeInvokesChaincode fails, seems to be a problem >with the hardcoded chaincode id (hash) in example04 >patchset 15: I changed the ID to the one I saw in the Jenkins logs. the ChaincodeInvokes... test works OK on >Jenkins, but locally, it fails >So the hash of example02 that is called by example04 (that is why example04 contains the hash of it) seems to >be different on my machine and on Jenkins??? How?

hgabor
2016-08-10 08:38
it is very funny - it seems that the local machine and the jenkins has different hashes for that file

bgorman
2016-08-10 08:38
yeah my best guess was example02 changed hash... so I've been trying to correct it, but I haven't had much success

hgabor
2016-08-10 08:39
I was able to correct it locally -> but that resulted that Jenkins did not work (the test failed) and if I corrected it according to Jenkins' hash printouts it began to fail locally but worked in Jenkins

bgorman
2016-08-10 08:41
oh ok... I'd be interested in how you fixed it locally

hgabor
2016-08-10 08:44
1 minute and I will tell you :-)

bgorman
2016-08-10 08:44
I see example02 has not changed

hgabor
2016-08-10 08:53
1) run that failing test locally, cd into core/chaincode, execute go test -run "ChaincodeInvokeChaincode" - this will run 2 tests, chaincodeinvokechaincode and chaincodeinvokechaincodeerrorcase. 2) search for the hashes in the logs. they are part of docker container names which look like this: dev-jdoe-HASH_IS_HERE ; One of those hashes is for example02, grab it and put it into example04.go in examples/chaincode/go. at the top of the file there is a variable (chaincodetocall or something) the value of which must be the hash.

hgabor
2016-08-10 08:54
which one of those hashes is the hash of example02? this can be found out from the logs and/or by trying :slightly_smiling_face:

hgabor
2016-08-10 08:57
btw it would be good if you could send me your logs

hgabor
2016-08-10 08:57
@bgorman

muralisr
2016-08-10 12:25
@hgabor: I too did not see a difference in chaincode_example02

muralisr
2016-08-10 12:26
from the one you sent me from jenkins and local

muralisr
2016-08-10 12:27
btw, the whole point of hardcoding chaincode_example02’s hash in example04 was to catch these kind of issues

muralisr
2016-08-10 12:28
if nothing else changes, the hash should be identical

hgabor
2016-08-10 12:39
simon had an idea: maybe there was something in my chaincode example directory. something that was not under version control. but if this was it, how did it work for Zsolt? Or did he overlook something else? Maybe yes

hgabor
2016-08-10 12:40
now, I have an even newer patchset, waiting for Jenkins build


hgabor
2016-08-10 12:40
:slightly_smiling_face:

muralisr
2016-08-10 13:17
yeah, that was my thought too … however, I didn’t see anything extra in the tar you sent

muralisr
2016-08-10 13:17
unless it is a VERY transient thing

hgabor
2016-08-10 13:20
we could have a wiki about these things. I mean if any newbie (like me) starts to hack things related to chaincodes... it is good to know

muralisr
2016-08-10 13:21
well, we need to get to the bottom of this first

simon
2016-08-10 13:37
we shouldn't fix this with documentation

simon
2016-08-10 13:37
we should fix it with code

hgabor
2016-08-10 13:38
how?

muralisr
2016-08-10 13:42
sorry… fix what ?

simon
2016-08-10 13:42
the fact that hashes disagree

hgabor
2016-08-10 13:43
yes but my repo was polluted (or at least this is the most probable theory :slightly_smiling_face: )

muralisr
2016-08-10 13:43
we need to get to the bottom of why they disagree first

simon
2016-08-10 13:43
because the sources are different

simon
2016-08-10 13:43
some residual editor files

simon
2016-08-10 13:43
etc.

muralisr
2016-08-10 13:44
we cannot fix until we know exactly what’s causing the difference…. in the worst case, what if the hash function computes differently on the same bytes ?

muralisr
2016-08-10 13:46
@hgabor : what’s hte current run doing to help ?

muralisr
2016-08-10 13:46
are you outputting some data or something ?

hgabor
2016-08-10 13:48
the "erroneous" test worked on my local machine (in chaincode_example04, I wrote the same ID that worked for Jenkins, last time). now, I am waiting for Jenkins results. Btw: I did nothing else just git clean.

hgabor
2016-08-10 13:50
in a nutshell, if Jenkins says OK this time that means that I cannot reproduce the fault anymore. which is half good half bad

hgabor
2016-08-10 13:51
It seems that Jenkins is running behave tests. So the error "is gone".

hgabor
2016-08-10 13:51
And once again, I only did git clean.

ry
2016-08-10 13:52
Jenkins always starts from 0. It's a new VM and (obviously) fresh check out

hgabor
2016-08-10 13:53
yep, but my local does not always start from 0. :slightly_smiling_face: it should but...

hgabor
2016-08-10 13:55
verification takes a lot of time...

simon
2016-08-10 13:56
i think it is too easy to have some file debris in the chaincode directories and then mix up the hash

simon
2016-08-10 13:56
it needs to be fixed

hgabor
2016-08-10 13:57
I am not sure if this is a feature or a bug. One can have opinions for both

simon
2016-08-10 14:04
bug

hgabor
2016-08-10 14:06
do you think it would be needed to filter some specific filetypes or..?

muralisr
2016-08-10 14:07
we cannot differentiate between what is a “good” file and a bad

muralisr
2016-08-10 14:08
note that this is the first time that some “debris” entered the picture

hgabor
2016-08-10 14:08
@muralisr I must agree

muralisr
2016-08-10 14:08
other times it was actually a change to the chaincode itself

muralisr
2016-08-10 14:09
honestly, I’m a bit scared that the bytes are same but somehow the two envs compute different hash

muralisr
2016-08-10 14:09
now that would be REALLY bad

hgabor
2016-08-10 14:10
if you have any idea how I could reproduce it I can try

muralisr
2016-08-10 14:13
i missed that git clean appeared to have fixed it… adds support to the “debris” theory


simon
2016-08-10 16:45
bug in crypto code!

grapebaba
2016-08-11 04:26
does anyone know how to get email notification when JIRA task created?

ry
2016-08-11 04:32
grapebaba: I think it is a per-account preference in JIRA you would need to set for yourself

hgabor
2016-08-11 07:35
[Hyperledger-fabric] About transaction IDs and replay attack everybody from that list, please have a look at this mail thread and help us decide the right method of TxID generation (more about this in the thread, please read)

muralisr
2016-08-11 11:40
@hgabor: adding @adc incase not in the list

hgabor
2016-08-11 11:46
thanks

simon
2016-08-11 11:49
what list?

simon
2016-08-11 11:50
why do we have a slack if half of the stuff is communicated via mail?

adc
2016-08-11 12:46
@hgabor, I almost agree with Tamas, meaning signing everything but cert and signature. I'm just trying to understand if attacks can be mounted and then I will reply :slightly_smiling_face:

hgabor
2016-08-11 12:47
@adc do you mean including everything in the generation of TxID except cert and signature?

adc
2016-08-11 13:01
yes

adc
2016-08-11 13:01
because that's the content of the transaction

adc
2016-08-11 13:02
it is the only thing we care about

adc
2016-08-11 13:02
and is protected by the signature

adc
2016-08-11 13:02
now, if the transaction is about money transfer, let's say, Alice transfers to Bob 10 USD,

adc
2016-08-11 13:03
if Bob mauls the transaction signature and replay

adc
2016-08-11 13:03
it will be caught

adc
2016-08-11 13:04
if Bob replays only the content and sign it with one of his certificate, then the chaincode should ensure that only Alice can do this operation

adc
2016-08-11 13:04
this is related to access control

muralisr
2016-08-11 13:05
@adc is that enough to make the TID unique ? [transfer Alice, bob, 10] twice is valid and not unique

muralisr
2016-08-11 13:05
but perhaps there are other things besides just “payload” in composing a TID

adc
2016-08-11 13:05
yeah, let's discuss this

adc
2016-08-11 13:06
for confidential transaction

adc
2016-08-11 13:06
(or proposal)

adc
2016-08-11 13:06
the hash will be on ciphertexts

adc
2016-08-11 13:06
which will be always different

adc
2016-08-11 13:06
so no issue here

adc
2016-08-11 13:06
but

adc
2016-08-11 13:06
for public transactions/proposals

adc
2016-08-11 13:06
we need a nonce

adc
2016-08-11 13:06
indeed, the nonce is good to have also for confidential transactions

adc
2016-08-11 13:08
but for other reasons

muralisr
2016-08-11 13:13
ok.. for some reason I thought we wanted to go away from nonce… but maybe I was mistaken. Can you remind ?

adc
2016-08-11 13:14
I didn't want to go away for it because it is helpful and for public transactions it is evident. If Alice wants to transfers 2 times 10 USD to Bob, the content of the transaction can potentially be the same and so to avoid replays the nonce can help

adc
2016-08-11 13:15
I think @binhn was arguing that the nonce can be avoided because at some point during the protocol the endorser can figure it out

adc
2016-08-11 13:15
more details are needed

simon
2016-08-11 13:16
what replay are we trying to prevent?

adc
2016-08-11 13:16
proposal

adc
2016-08-11 13:16
no?

simon
2016-08-11 13:16
of an attacker?

simon
2016-08-11 13:16
or of a byzantine node

simon
2016-08-11 13:16
by*

adc
2016-08-11 13:16
attacker in the first place

adc
2016-08-11 13:16
as the example I was mentioning above

simon
2016-08-11 13:17
don't we use TLS connections?

adc
2016-08-11 13:17
still, suppose that the attacker gets that transaction in some other way

adc
2016-08-11 13:17
because he attacked an endorser

simon
2016-08-11 13:17
so byzantine endorser

adc
2016-08-11 13:17
or because he was listening at Alice before Alice send to the TLS channel

simon
2016-08-11 13:18
who replays the proposal to whom?

simon
2016-08-11 13:18
in what communication step

adc
2016-08-11 13:18
in that case the endorser is not byzantine, it is cursious buthonest

adc
2016-08-11 13:18
let's recap

adc
2016-08-11 13:19
Alice send a proposal for transferring 10 USD to Bob

simon
2016-08-11 13:19
who is alice

simon
2016-08-11 13:19
client?

adc
2016-08-11 13:19
yes

adc
2016-08-11 13:19
sorry

simon
2016-08-11 13:19
bob is endorser?

adc
2016-08-11 13:19
nono

adc
2016-08-11 13:19
Alice and Bob are two parties

adc
2016-08-11 13:19
who are transacting

simon
2016-08-11 13:19
application level?

adc
2016-08-11 13:19
yes

simon
2016-08-11 13:19
then it is no fabric data structure

adc
2016-08-11 13:20
we are trying to avoid that the same proposal is accepted two times

simon
2016-08-11 13:20
yes, but what entity in the network is sending this proposal to what other entity

adc
2016-08-11 13:20
the client-sdk

adc
2016-08-11 13:20
it is not the submitting peer

simon
2016-08-11 13:20
to?

adc
2016-08-11 13:21
to the endorsers directly

simon
2016-08-11 13:21
right

simon
2016-08-11 13:21
but that's a tls connection

adc
2016-08-11 13:21
right

adc
2016-08-11 13:21
but let's suppose that the attacker gets the proposal in some other way

adc
2016-08-11 13:21
he can then replay

simon
2016-08-11 13:21
how?

simon
2016-08-11 13:21
the attacker needs a tls connection to the endorser

adc
2016-08-11 13:21
I don't know, the ways to reach god are infinite

adc
2016-08-11 13:22
yes, it is fine

adc
2016-08-11 13:22
the attacker has a tls connection to the endorsers

adc
2016-08-11 13:22
let's say the attacker control the network

simon
2016-08-11 13:22
sure

adc
2016-08-11 13:23
we are really going to the extreme here

simon
2016-08-11 13:23
but with tls, network control only means interruption

adc
2016-08-11 13:23
right

adc
2016-08-11 13:23
this is the reason I said, the attacker gets the proposal in some other way

adc
2016-08-11 13:23
because he taps into Alice

simon
2016-08-11 13:23
right, but then the proposal doesn't match the attacker's identity

adc
2016-08-11 13:24
or because he gets this information passed by an endorser who is honest but curious

adc
2016-08-11 13:24
mh, interesting.. what does that mean?

simon
2016-08-11 13:24
well, there is a tls connection

simon
2016-08-11 13:24
which identifies the attacker as party Eve

simon
2016-08-11 13:24
which doesn't match Alice's identity

adc
2016-08-11 13:25
what if the proposal is signed with a TCert?

adc
2016-08-11 13:25
there is no identity on the proposal

simon
2016-08-11 13:25
aha

simon
2016-08-11 13:25
then you made your life harder

adc
2016-08-11 13:25
I am

adc
2016-08-11 13:25
I want to consider the worst scenario

simon
2016-08-11 13:26
the worst scenario is everybody is compromised and nothing is safe

simon
2016-08-11 13:26
or you mean worst configuration

adc
2016-08-11 13:26
no comeon, that's too much :slightly_smiling_face:

simon
2016-08-11 13:26
so sdk signs a proposal

adc
2016-08-11 13:26
I mean, there are at least a certain number of non-corrupted entities

simon
2016-08-11 13:26
and somehow this gets leaked

adc
2016-08-11 13:26
yes

adc
2016-08-11 13:27
it can be leaked at the endpoints

adc
2016-08-11 13:27
I agree not at TLS layer

simon
2016-08-11 13:27
so replay protection on the transport layer

adc
2016-08-11 13:28
I would say at the application layer

adc
2016-08-11 13:28
because TLS already has that

simon
2016-08-11 13:28
yea i guess that's what i mean

adc
2016-08-11 13:28
perfect

simon
2016-08-11 13:28
so you establish a nonce for the new tls connection

simon
2016-08-11 13:29
hm no

simon
2016-08-11 13:29
why is the proposal signed at all?

simon
2016-08-11 13:29
where does this trust get transferred?


adc
2016-08-11 13:31
for this let's wait the final message flow. The discussion started on how to construct txID and I was investigating the relation with replay attacks

adc
2016-08-11 13:31
so I started speculating

simon
2016-08-11 13:31
right

adc
2016-08-11 13:31
so, I'm now fine with Tamas' proposal

adc
2016-08-11 13:31
hash everything but cert and signature

simon
2016-08-11 13:32
i don't care for this application level stuff

simon
2016-08-11 13:32
what i care about is what falls out of the endorsers

simon
2016-08-11 13:32
i'm pretty sure that getting rid of the submitting peer is a bad idea

simon
2016-08-11 13:32
but oh well

adc
2016-08-11 13:32
mh interesting, why?

adc
2016-08-11 13:33
I'm also trying to understand

adc
2016-08-11 13:33
the pros and cons

simon
2016-08-11 13:38
it's about optimizing the endorser execution

simon
2016-08-11 13:39
if you know what changeset you expect to be produced, you can use a proxy to shard the chaincode simulation across different machines which have different working sets in memory, etc.

simon
2016-08-11 13:39
if you don't know it, you basically need to blindly execute

yaoguo
2016-08-11 18:17
hi, everyone. How can i ref JIRA issue in gerrit pr?

ry
2016-08-11 18:18
yaoguo: if the bug is FAB-4 (for instance) start your commit message like:

ry
2016-08-11 18:18
FAB-4: Fix frobnicator allocation

yaoguo
2016-08-11 18:22
Thanks.

ry
2016-08-11 18:27

ry
2016-08-11 18:27
if you look here: https://jira.hyperledger.org/browse/FAB-1 you will see 389 shows up in the git commits tab and the git rollup tab

yaoguo
2016-08-11 18:31
My commit is "FAB-3: Fix Json output for empty network list" . Is there anything incorrect? JIRA has no response.

ry
2016-08-11 18:59
did you mean to re-open https://jira.hyperledger.org/browse/FAB-1, or was that an accident

ry
2016-08-11 19:00
yaoguo: once https://gerrit.hyperledger.org/r/#/c/485/ is merged it will link up to JIRA

yaoguo
2016-08-12 01:08
oh, I see. I thought it will be linked after pushing the commit just like github PR.

bgorman
2016-08-12 01:52
I closed FAB-1 again

yaoguo
2016-08-12 02:48
Sorry for FAB-1 misoperation. The latest code build failed by Jenkins because some core.util unit-test. It blocks all the new commits building. Make a commit to fix it in https://gerrit.hyperledger.org/r/#/c/489/.

ry
2016-08-12 04:42
@yaoguo: 489 doesn't seem to build either

bgorman
2016-08-12 04:57
is the gradle stuff in the build new? it doesn't seem to function behind a proxy

bgorman
2016-08-12 05:03
I'm also not a fan of the new [][]byte input to the chaincodes instead of []string... it seems to simplify the use case of raw binary args at the expense of the simplest use cases (like example02)

bgorman
2016-08-12 05:04
peer chaincode deploy -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}' no longer works as you need to base64 encode the arguments now

bgorman
2016-08-12 05:05
the REST API is also affected

hgabor
2016-08-12 05:40
@bgorman https://gerrit.hyperledger.org/r/#/c/481/ the cli will work with string. the REST API is for programming, from that side a [][]byte / base64 should be easier/simpler than a string

bgorman
2016-08-12 05:40
my CLI does not work

bgorman
2016-08-12 05:40
Error: Chaincode argument error: illegal base64 data at input byte 0

bgorman
2016-08-12 05:41
and I disagree, a plain text string is the simplest thing you can send... base64ing that string is an added layer of complexity

bgorman
2016-08-12 05:42
it will break using the Swagger-UI with blockchain

hgabor
2016-08-12 05:42
yes it does not work yet but the commit I sent you will be the fix

hgabor
2016-08-12 05:43
and base64ing comes from golang json. and I do not think real life chaincodes want to send strings instead of structures encoded into bytes

hgabor
2016-08-12 05:43
real life chaincodes are more complex than "send", "11", "Alice"

hgabor
2016-08-12 05:44
and they should be interacted by programs, not manually

bgorman
2016-08-12 05:44
are they? plenty of applications accept simple JSON arguments... not binary blobs

hgabor
2016-08-12 05:45
yes but these are not just applications, this is a general thing for chaincodes

bgorman
2016-08-12 05:45
I get that someone will want to send binary data.... but why can't they just base64 encode their binary blobs into an argument and unmarshal it inside their chaincode?

hgabor
2016-08-12 05:45
and I guess most of the chaincodes in real life will do something e.g. with financial things - think of BTC, I would not think string would be enough for that

hgabor
2016-08-12 05:46
with financial things I wanted to mean that more complex things

bgorman
2016-08-12 05:46
sure, but why not make those apps responsible for their unmarshalling instead of imposing base64 input on everyone?

hgabor
2016-08-12 06:00
3 things: 1) from a go point of view, []byte is nearly the same as string. And for a program []byte is easier and general to handle cause of the ability of structure encoding. 2) the B64 things is caused by just the golang json implementation. as I see it could be just a string as that could be easily converted to []byte. and then everything would be the same from the REST point of view. 3) despite 2) I think that for programs it is not a hardness to use base64 because I am nearly sure that a simple 1 liner can do that conversion. but they can surely benefit from []byte instead of string.

hgabor
2016-08-12 06:00
but the best thing would be to find some solution that is good for everyone, e.g. for You and me

hgabor
2016-08-12 06:02
I have been thinking on solutions but only came up with the worst practice thing that we could modify golang json source - big no-no

bgorman
2016-08-12 06:06
[][]byte and []string being so similar means it should be easy for your program to convert from []string to [][]byte (in a simple 1 liner)

bgorman
2016-08-12 06:07
then it could do its structure encoding from there

bgorman
2016-08-12 06:07
I guess I'm a fan of simple APIs...

hgabor
2016-08-12 06:17
but as I understand your only problem is that this whole byte things manifests itself in the REST API as base64

bgorman
2016-08-12 06:21
that and it makes the chaincode more complicated

abhishekseth
2016-08-12 06:23
has joined #fabric-dev

hgabor
2016-08-12 06:23
why are bytes more complicated than string?

bgorman
2016-08-12 06:24
because if you're not dealing with binary data, then you need a whole bunch of helper functions

hgabor
2016-08-12 06:26
you are not dealing with binary data if you only use example02. the question is whether real life applications will be similar to example02

hgabor
2016-08-12 06:27
btw which helpers did you mean?

bgorman
2016-08-12 06:29
things like getFunctionAndParams()

bgorman
2016-08-12 06:29
and ToChaincodeArgs()

bgorman
2016-08-12 06:34
you're right though, it's about the use cases, maybe mine are too simple and people will always want to ship binary blobs around

hgabor
2016-08-12 06:36
but those will be eliminated.

hgabor
2016-08-12 06:36
the chaincode will only use stub. see Sheehan's proposal on the mailing list, he asked the devs/architects if they like it and only got positive comments.

hgabor
2016-08-12 06:38
but this leads to a chaincode API change and I wanted to avoid that in my commit as it was already large and had a big impact

hgabor
2016-08-12 06:38
so that change is WIP

bgorman
2016-08-12 06:39
sorry, I don't follow the mailing lists.... do you have a link or a time/date I can check for?

yaoguo
2016-08-12 07:00
@ry: Updated 489.

bgorman
2016-08-12 07:01
489 and 491 seem to be fixing the same thing?

yaoguo
2016-08-12 07:04
Yes. Basicly, they're same.

hgabor
2016-08-12 07:06
bgorman: I will try to give you something like that

hgabor
2016-08-12 10:38

simon
2016-08-12 11:02
why don't i see this in my overview?

simon
2016-08-12 11:03
oh

simon
2016-08-12 11:03
because i had the wrong view

simon
2016-08-12 11:03
WOW

simon
2016-08-12 11:03
there are so many outstanding ones

simon
2016-08-12 11:04
hgabor: "fix failing test" is not a good subject

hgabor
2016-08-12 11:09
maybe now? what would be better?

simon
2016-08-12 11:10
why does jenkins run when only the commit message changes?

simon
2016-08-12 11:11
ry: ramesh: can we change that?

hgabor
2016-08-12 11:11
it generates a new patchset and our Jenkins is not enough intelligent to know

hgabor
2016-08-12 11:11
that is was only a commit message change

simon
2016-08-12 11:11
yea

hgabor
2016-08-12 11:11
we can check it using git commands somewhere in the Jenkins job

simon
2016-08-12 11:12
basically if the treeish is the same, no need to rerun

hgabor
2016-08-12 11:12
maybe it can be done without checking it from shell. I mean maybe Jenkins can check it

simon
2016-08-12 11:20
yes

simon
2016-08-12 11:21
don't look at the commit, but at the tree

hgabor
2016-08-12 11:26
some offtopic: do we need all these apps?? I could add email app that could announce emails on the mailing lists to channels... I guess 3/4 of ppl here do not read emails from those lists so it would be cool. https://hyperledgerproject.slack.com/apps/manage

simon
2016-08-12 11:31
lots of apps

hgabor
2016-08-12 11:31
10 apps can be installed on a free slack

hgabor
2016-08-12 11:31
we have 10 apps

simon
2016-08-12 11:32
great

simon
2016-08-12 11:32
angellist

simon
2016-08-12 11:32
i think we should remove that

hgabor
2016-08-12 11:33
me too

hgabor
2016-08-12 11:33
who will press the remove button? :smile:

simon
2016-08-12 11:45
oh look

simon
2016-08-12 11:45
there are app spots free now

hgabor
2016-08-12 11:47
hmm what could have happened


hgabor
2016-08-12 11:47
what do you think of this?

hgabor
2016-08-12 11:50
btw we have exactly 10 apps now, before we had 11 :S

muralisr
2016-08-12 11:56
can we revist @bgorman ’s comments on the need for change from []string to [][]bytes ? I can see both points of view. However if most of the arguments are expected to be strings, [][]bytes would be inefficient. Whatever is decided is fine. However this is a direct user experience question and has to be thought out carefully

simon
2016-08-12 11:57
why inefficient?

muralisr
2016-08-12 11:58
ux.

muralisr
2016-08-12 11:59
representation would change at the user interface level

simon
2016-08-12 11:59
what user interface?

simon
2016-08-12 11:59
you mean API?

hgabor
2016-08-12 12:01
@muralisr: yes, I think it is time to revisit it

hgabor
2016-08-12 12:02
@muralisr: as I see the only problematic part is the REST API.

hgabor
2016-08-12 12:04
@muralisr: I may be wrong but for me, it seems that it would be enough to somehow "make the REST API work with strings". in the background, it is OK if the chaincode input contains [][]byte and not []string

hgabor
2016-08-12 12:04
what do you think?

muralisr
2016-08-12 12:15
I’d love to know answer to “what is more common input to transactions ? Strings or byte objects (such as jpegs, zip files, etc…)

muralisr
2016-08-12 12:15
note that it also affects other chaincode env besides go

hgabor
2016-08-12 12:16
and the bytes can also be used for proto structs

muralisr
2016-08-12 12:16
true

muralisr
2016-08-12 12:16
all forms of bytes

hgabor
2016-08-12 12:16
and strings

muralisr
2016-08-12 12:17
well, I’d keep “strings are also bytes” argument out of this one. If most of the times we deal with strings, question is should that be the representation

simon
2016-08-12 12:17
why?

simon
2016-08-12 12:17
it's a general purpose thing, we cannot assume that strings will be used most of the time

hgabor
2016-08-12 12:18
I meant bytes can be string cause of the 1-1 mapping

muralisr
2016-08-12 12:18
in java ?

simon
2016-08-12 12:18
i'd even argue that strings shouldn't be used most of the time, because they are an inefficient reprensentation for anything except actual strings

muralisr
2016-08-12 12:18
that’s my question. Is most of that time are inputs actual strings

hgabor
2016-08-12 12:19
In Java, string makes it hard to encode anything, bytearray makes it easier - I think

hgabor
2016-08-12 12:19
I can only talk about the examples, they all use strings,

muralisr
2016-08-12 12:19
no, forget the examples

hgabor
2016-08-12 12:19
I do not know about user code

muralisr
2016-08-12 12:20
they are just toys

simon
2016-08-12 12:20
right

simon
2016-08-12 12:20
we don't know anything

simon
2016-08-12 12:20
therefore it should be bytes

muralisr
2016-08-12 12:20
that’s not true

muralisr
2016-08-12 12:20
http has gotten quite well with strings

simon
2016-08-12 12:20
wat

muralisr
2016-08-12 12:20
and when they had to convert, the convert

simon
2016-08-12 12:21
http is oblivious to the content

simon
2016-08-12 12:21
that's why you can download binaries

muralisr
2016-08-12 12:21
correct

simon
2016-08-12 12:21
rfc2822 is not, that's why you have to base64 encode your attachments

muralisr
2016-08-12 12:22
but they don’t say all uri’s should be base64 encoded

muralisr
2016-08-12 12:22
time for office…later

simon
2016-08-12 12:23
but these are not uris

simon
2016-08-12 12:23
the chaincode name is the equivalent of an URI

simon
2016-08-12 12:24
the arguments are the equivalent of POST parameters

simon
2016-08-12 12:24
(which don't work well)

hgabor
2016-08-12 12:24
btw as I know there is (devops - will be deprecated) and there will be interfaces other than the REST

simon
2016-08-12 12:25
we're talking about the arguments to the chaincode, which should really be discussed in the context of chaincode

simon
2016-08-12 12:25
i think it is simple. chaincode can store bytes in state, so why shouldn't chaincode receive bytes from arguments

hgabor
2016-08-12 12:27
I think byte is the most general

simon
2016-08-12 12:28
yes, of course

simon
2016-08-12 12:28
otherwise we should require an encoding for the strings

simon
2016-08-12 12:28
e.g. utf-8

simon
2016-08-12 12:29
and possibly even a format, like json

hgabor
2016-08-12 12:30
that would be an overkill (I think): encoding over encoding

simon
2016-08-12 12:32
This integration is only available to teams on paid plans. Learn more

simon
2016-08-12 12:32
:confused:

simon
2016-08-12 12:32
no mail for us

hgabor
2016-08-12 12:34
if you click on learn more it takes you to the prices page, doesnt it? I guess then it means that we still have too much apps (we have 10 apps now - 10 is free for unpaid. we had 11 before, I do not know how)

synechist
2016-08-12 12:37
has joined #fabric-dev

simon
2016-08-12 12:38
hgabor: ah

hgabor
2016-08-12 12:39
but not sure it works that way

simon
2016-08-12 12:39
no, i think in general it costs money to use it

simon
2016-08-12 12:40
maybe have to write our own

simon
2016-08-12 12:40
using blockchain

gennady.laventman
2016-08-12 12:44
Hi. I did some work to add flow control to all communication streams (events, peer and chaincode). I opened jira issue (https://jira.hyperledger.org/browse/FAB-38) and have some working code. How do I proceed with gerrit from here?

simon
2016-08-12 12:45
if you're happy with the code, submit it to gerrit

simon
2016-08-12 12:45
and ask people to review it

gennady.laventman
2016-08-12 12:47
Ok, how I choose reviewers?

simon
2016-08-12 12:48
pick somebody you think would be familiar with the code

simon
2016-08-12 12:48
or just talk to us here

gennady.laventman
2016-08-12 12:49
ok, thanks.

muralisr
2016-08-12 13:04
@gennady.laventman: I assume the work will work for java chaincode seamlessly ?

gennady.laventman
2016-08-12 13:05
It should, I didn’t touched shim code at all, so based on assumption that java shim works same way as go shim, it should work

gennady.laventman
2016-08-12 13:07
Do any tests (behave, unit-tests) check java shim, so I could check it?

muralisr
2016-08-12 13:11
ok

muralisr
2016-08-12 13:12
that’s fine then

muralisr
2016-08-12 13:12
(no need to check….thank you, though!)

simon
2016-08-12 13:14
how does that flow control work?

gennady.laventman
2016-08-12 13:15
Once I will finish merge with gerrit head, will submit code for review.

gennady.laventman
2016-08-12 13:22
I put some info in jira issue, but naive implementation just add 2 channels - in and out for each stream. Now instead of calling stream.Send, handler call new Send impl, that just put message to channel and go routing will move it from channel to real stream. Same with stream.Recv and handler.HandlerMessage: streamRecv runs in endless for loop (as before), but instead calling handler.HandlerMessage direct, it put message in channel and another routing takes message from channel and invoke handler.HandlerMessage

gennady.laventman
2016-08-12 13:24
Introducing this intermediate layer allow in future add more robust flow control, like sending messages back to sender, with request to stop sending, etc, without changing handlers logic

simon
2016-08-12 13:28
why is the current code inadequate?

hgabor
2016-08-12 13:31
@muralisr: do you think the REST API would be still problematic if one could use strings istead of base64? the chaincode invocation args would remains [][]byte

simon
2016-08-12 13:32
i never understood the need for "chaincodeinvocationspec"

simon
2016-08-12 13:32
why don't we send a transaction?

hgabor
2016-08-12 13:34
@simon I think sending a transaction is fundemental for the content generated ID. with the current implementation it is hard to implement it (content generated using the whole transaction). And as I know the new architecture will send transactions instead of invocations.

gennady.laventman
2016-08-12 13:34
@simon: It is not, but you don’t have any control - you can’t see if you process incoming messages much slower that they come in or send messages out to fast will cause Send to block. Now you have control over it - at least you will not block on Send and stop all state machine

simon
2016-08-12 13:36
hgabor: good

gennady.laventman
2016-08-12 13:36
@simon: No, not correct - you still can block, but you have another option(s), fail during send and take care of the failure

simon
2016-08-12 13:37
gennady.laventman: what failure?

muralisr
2016-08-12 13:39
@hgabor: with REST either representation with affect the other type … the question is what is used most often. end user inputs will typically be strings… and in general I’d think there’d be a lot more strings. But I grant that, easier to go from bytes to string than the other way round (base64 etc)

gennady.laventman
2016-08-12 13:41
@simon: Now, for example, you can block on Send to stream. In new design, with flow control, as developer, you can still implement it in same way (handler blocks on Send) or you can make Send to fail in this case and change handler logic to take care of it.

simon
2016-08-12 13:43
gennady.laventman: i think in general, state machine operations should be non-blocking, so this in principle is good

simon
2016-08-12 13:44
but my experience is that goroutines add to non-determinism and complex behavior

hgabor
2016-08-12 13:45
@muralisr: but I think this is only true for golang json that it needs base64 if you want to decode as byte array. this is not a json rule or a REST rule, this is just a golang implementational thing

hgabor
2016-08-12 13:45
@muralisr: how to decide which to use? (string vs []byte)?

simon
2016-08-12 13:46
trivial, you use the more general one

gennady.laventman
2016-08-12 13:46
@simon: Indeed, so I just limited myself to 2 for each stream. And hope I have all stop issues covered. But this is tests and code reviews are for

muralisr
2016-08-12 13:47
@gennady.laventman: I still don’t get the “flow control” part. Are there things like message buffers and retries etc ? perhaps I should go read code :slightly_smiling_face: ?

muralisr
2016-08-12 13:47
@hgabor: I thought I was giving a point in your favor with the last statement of the comment :slightly_smiling_face:

simon
2016-08-12 13:47
sounds more like asynchronous send

simon
2016-08-12 13:48
submit it to gerrit and we can easily talk about it

gennady.laventman
2016-08-12 13:48
Channels are play buffers role, no retires yet. Once I finish to merge it with current head, will submit it.

muralisr
2016-08-12 13:49
@hgabor: if represented as bytes I can convert to strings easy but if represented as strings ‘ll have to encode bytes

hgabor
2016-08-12 13:49
@muralisr yes but it seems that e.g. Chris does not agree that much https://gerrit.hyperledger.org/r/#/c/499/

hgabor
2016-08-12 13:49
(I have to go, I will be back soon)

muralisr
2016-08-12 13:50
@hgabor: right there’s that problem in the sender side… I was talking about receiver

gennady.laventman
2016-08-12 13:50
I started to work on it more that 2 weeks ago and it still in github, so nice experience with moving it to gerrit and merging ahead of me.

simon
2016-08-12 13:50
it's simple

simon
2016-08-12 13:50
do this:

simon
2016-08-12 13:52
```git remote add gerrit ssh://$LFUSER@gerrit.hyperledger.org:29418/fabric.git git remote update echo 0716064b25428ea2426fa589db365c419726b24b 346f9fb448140e931fed73b46f528de6dacbc0d0 > .git/info/grafts```

simon
2016-08-12 13:52
well, imagine without linebreak in the echo line

simon
2016-08-12 13:53
because why care about what i write...

simon
2016-08-12 13:53
now you should have a history on the gerrit/master that reaches to the beginning of time

simon
2016-08-12 13:53
then you should be able to easily do a rebase

simon
2016-08-12 13:53
onto gerrit/master

gennady.laventman
2016-08-12 13:56
ok, thanks. will do it. although, not promising to finish it today - I want to write little bit more tests, to make sure I didn’t broke anything

simon
2016-08-12 14:01
sure

simon
2016-08-12 14:01
you can do a WIP submission

maheshpatil13
2016-08-14 07:00
Anyone has tried to install the dev environment on direct ubuntu machine if so what are the step or any document or link can help.

destenson
2016-08-14 19:11
has joined #fabric-dev

bgorman
2016-08-15 06:07
what happened to the jenkins builds?

bgorman
2016-08-15 06:07
#332 (pending—All nodes of label ‘hyp-fabric-x86_64’ are offline)

ry
2016-08-15 07:17
@bgorman: there was an unplanned outage this weekend. We're still recovering

bgorman
2016-08-15 07:18
@ry ok, as long as someone knows :slightly_smiling_face:

ry
2016-08-15 07:23
Oh, we know :grinning:

mkabanau
2016-08-15 09:32
has joined #fabric-dev

nickgogerty
2016-08-15 14:46
has joined #fabric-dev

jblaszczyk
2016-08-15 18:59
has joined #fabric-dev

hgabor
2016-08-16 05:39
Could anybody review these?

hgabor
2016-08-16 05:39
this enables to use NON-base64 data but just from the cli: https://gerrit.hyperledger.org/r/#/c/481/ this is the updated docs: https://gerrit.hyperledger.org/r/#/c/499/

hgabor
2016-08-16 05:39
These are patches for the [][]byte args commit

bgorman
2016-08-16 06:18
@hgabor the peer code calling into the chaincode shim seems... odd

bgorman
2016-08-16 06:19
I get that it is a helper function though

hgabor
2016-08-16 06:25
See the comments about the code duplication I made first

hgabor
2016-08-16 06:26
Maybe that helper could have a better place

bgorman
2016-08-16 06:26
yeah... I'm just wondering if there's a central place for helper functions across the project

bgorman
2016-08-16 06:27
something like core/chaincode/helpers.go I guess

bgorman
2016-08-16 06:27
I'm not sure if a new package is warranted

hgabor
2016-08-16 06:52
I think creating a new for just this would be overkill

hgabor
2016-08-16 06:58
what would be the best solution?

hgabor
2016-08-16 07:04
@bgorman

bgorman
2016-08-16 07:08
not sure sorry, I just thought it was weird to have the peer using the shim

bgorman
2016-08-16 07:08
ignore me if you like :slightly_smiling_face:

hgabor
2016-08-16 07:15
it would be good to have those commits on master soon, so I would like to fix any issues asap

ry
2016-08-16 08:07
I heard an interesting idea from the former BDFL of ZeroMQ. Merge everything that builds to master when it comes in. Assume people have good intentions

ry
2016-08-16 08:10
In this episode somewhere: The Changelog: 205: A Protocol For Dying with Pieter Hintjens https://overcast.fm/+I_p2t9VU

hgabor
2016-08-16 08:12
I think that would result in chaos

hgabor
2016-08-16 08:16
@ry I guess it is not a good strategy for me now to restart all the verify jobs for all my commits, right?

ry
2016-08-16 08:59
@hgabor: it is your call

ry
2016-08-16 09:00
@hgabor: I didn't change anything so it will still fail on maven

ry
2016-08-16 09:01
CPU is free. I won't mind if you retrigger the fabric jobs

hgabor
2016-08-16 09:01
I meant that so many fabric verify instances are trying to run

ry
2016-08-16 09:01
I have is set to do as many as 10 at once

ry
2016-08-16 09:06
The hardware limit on that slice is 2k cores IIRC.

ry
2016-08-16 09:07
So 10 builders are hardly a tax

hgabor
2016-08-16 09:53
what is the port of PeerClient?

hgabor
2016-08-16 13:16
can anyone help me with protobuf?

simon
2016-08-16 13:25
in general, i can

yacovm
2016-08-16 14:15
I also have a weird problem with protobuf related to the project. I cloned the project from gerrit and all pb.go files are not compiling. The thing is, I'm sure this is 100% related to the project and not to the environment because I tested it by putting my own protobuf file inside the project and compiled it using protoc, and it doesn't get compiled well, but that same file compiles well *outside* of the project :confused: any ideas anyone?

yacovm
2016-08-16 14:16
um, simon, why did you label consensus to the gossip issue?

simon
2016-08-16 14:17
my mistake

simon
2016-08-16 14:17
do you prefer a different label?

yacovm
2016-08-16 14:17
no idea, maybe communication?

simon
2016-08-16 14:18
can you edit it to change the label?

yacovm
2016-08-16 14:20
You have any idea about the protobuf problem I have? I'm not using the dev env vagrant

simon
2016-08-16 14:23
can you explain what the problem is?

simon
2016-08-16 14:25
yacovm: what's the difference between fab-46, fab-35, and fab-45?

yacovm
2016-08-16 14:26
huh?

simon
2016-08-16 14:26
and fab-42

yacovm
2016-08-16 14:26
what are these

yacovm
2016-08-16 14:28
oh

yacovm
2016-08-16 14:28
jira issues?

tuand
2016-08-16 14:32
yes, jira issues transcribed from a list I gave clayton a while back ... @mandler and I had talked about your guys doing a prototype then connecting that to fabric so I just listed some possible tasks. If you want , you can replace what's in jira with your tasks list

yacovm
2016-08-16 14:33
but, what's a validator gossip?

simon
2016-08-16 14:33
i don't know

simon
2016-08-16 14:33
it says gossip, so it is your stuff :slightly_smiling_face:

yacovm
2016-08-16 14:33
and @simon, basically my problem is: I cloned from gerrit, ran "make protos" and the pb.go files won't compile

simon
2016-08-16 14:34
ah, i never used that

simon
2016-08-16 14:34
:slightly_smiling_face:

tuand
2016-08-16 14:35
oh FAB-45 ? network of validators using gossip when creating a block

yacovm
2016-08-16 14:35
ok... so basically my *actualy* problem is that I have a message.proto file I use for gossip gRPC stuff

yacovm
2016-08-16 14:35
and it won't compile when it is located under the project tree

yacovm
2016-08-16 14:35
but will compile outside

simon
2016-08-16 14:38
what's the error?

yacovm
2016-08-16 14:39
compilation errors, I think they're related to the version of the proto compiler

yacovm
2016-08-16 14:39
all kinds

yacovm
2016-08-16 14:53
ok I see now, running "make protos" somehow ruins these files

yacovm
2016-08-16 14:58
but still- from some reason, a valid pb.go file that is compiling outside the HL project is not compiling when inside the project... I think maybe it's related to the vendor folder. are we using some old protobuf version or something?

hgabor
2016-08-16 14:59
could anybody review this? https://gerrit.hyperledger.org/r/#/c/499/ as it works this way now, it would be good to let this in

yacovm
2016-08-16 15:05
@tuand , what do you mean by validators using gossip when creating a block?

tuand
2016-08-16 15:11
validators receive an ordered batch of tx from orderer service, put valid tx into a block, gossip on this block then commit

yacovm
2016-08-16 15:12
so they're called validators now I guess

yacovm
2016-08-16 15:12
got it, thanks

tuand
2016-08-16 15:15
well, the names are somewhat fluid right now so I' probably using the wrong term ... i'll ask binh to update his presentation

yacovm
2016-08-16 15:16
I knew them as "consenting peers"

jyellick
2016-08-16 16:25
@yacovm This is largely my fault. On our whiteboards we kept using "CP" as a label, which some people interpreted as "consenting peer" and some as "committing peer", so to try to disambiguate, starting calling that piece "validator" this should all be documented soon

silliman
2016-08-16 18:06
has joined #fabric-dev

jcarrivick
2016-08-17 05:12
Just as a general question, would the maintainers prefer we add them as reviewers manually, or let them choose which change requests they review?

ry
2016-08-17 05:17
@jcarrivick: an answer to a question you didn't ask, but there is a group you can add which adds the maintainers in toto, should you decide to do that.

jcarrivick
2016-08-17 05:17
oh cool, I didn't know about that group

jcarrivick
2016-08-17 05:18
Do you know how to add them like that?

jcarrivick
2016-08-17 05:18
ah figured it out

jcarrivick
2016-08-17 05:19
add cr-fabric to the reviewers list

ry
2016-08-17 05:20
yes

hgabor
2016-08-17 06:01
I would still need reviewers for this: https://gerrit.hyperledger.org/r/#/c/499/

hgabor
2016-08-17 06:32
@sheehan @simon @muralisr and anybody else please have a look at it :slightly_smiling_face:

hgabor
2016-08-17 06:33
and comments/suggestions are welcome on this: https://gerrit.hyperledger.org/r/#/c/507/

bgorman
2016-08-17 07:17
@hgabor what would you think if I managed to add a layer into the REST API to revert it to the old syntax? (without changing the Chaincode internal [][]byte format)

hgabor
2016-08-17 07:21
that would be the best think I could imagine to happen to the REST API :slightly_smiling_face:

hgabor
2016-08-17 07:22
@bgorman: I had discussions with the others how to modify it to make it look like it was before. But we did not come to an agreement.

hgabor
2016-08-17 07:22
what is your idea, how would you do it?

bgorman
2016-08-17 07:23
it's not quite working yet... but I added another "ChaincodeSpec"-like proto which is the same as the old one

bgorman
2016-08-17 07:23
then in rest_api.go ProcessChaincode() I convert from one ChaincodeSpec to the other (e.g. copying function into the args and base64 encoding them all)

hgabor
2016-08-17 07:24
it could also be fixed by using some interface structure inside the go code when unmarshalling JSON. that structure must have []string args instead of [][]byte. and then one has to convert from that structure to ChaincodeInput

hgabor
2016-08-17 07:25
(I realize now this is the same that you said)

bgorman
2016-08-17 07:25
:slightly_smiling_face:

hgabor
2016-08-17 07:27
okay then, we should do this

hgabor
2016-08-17 07:28
it is not clear whether we shuld use a new proto or just something defined inside our go source

bgorman
2016-08-17 07:28
I made a new proto, it made all the JSON unmarshalling easy

bgorman
2016-08-17 07:29
currently REST seems happy with the "deploy" but then the container fails behind the scenes

bgorman
2016-08-17 07:29
07:19:49.141 [chaincode] processStream -> ERRO 02f Got error: Expecting integer value for asset holding 07:19:49.141 [chaincode] Launch -> ERRO 030 sending init failed(Error initializing container 77b0a96347f912468417493de63799e40c21842b987785b30f3cf81a6116020b60f4a88380964704e35a5e32518fea93d11da773aa0b2292f674708d38328360: Expecting integer value for asset holding)

bgorman
2016-08-17 07:30
that looks like it's come from the example02 code itself

bgorman
2016-08-17 07:30
weird

bgorman
2016-08-17 07:32
it got the right number of args (4) but couldn't Atoi() them

hgabor
2016-08-17 07:34
isnt it the hash inside chaincode xample 04?

hgabor
2016-08-17 07:35
be back in 30 minutes

bgorman
2016-08-17 07:36
I'm just trying to deploy example02

bgorman
2016-08-17 07:40
looks like example02 is receiving the base64 args

bgorman
2016-08-17 07:41
e.g. arg1 == MTAw when it should be 100

ry
2016-08-17 07:43
hgabor: I made sure to spread maven around this time, if there are any other issues lmk

hgabor
2016-08-17 07:44
@ry thanks and okay

hgabor
2016-08-17 07:44
@bgorman: could you show some code in Gerrit?

ry
2016-08-17 07:44
I was going to try to upgrade docker today but I decided to stop messing with stuff when people are trying to work :slightly_smiling_face:

bgorman
2016-08-17 07:55
@hgabor sure, just let me figure out how :slightly_smiling_face:

bgorman
2016-08-17 08:04

jonathanlevi
2016-08-17 08:16
---

jonathanlevi
2016-08-17 08:16
All, I think that `master` is broken.

bgorman
2016-08-17 08:17
@jonathanlevi: is it related to https://gerrit.hyperledger.org/r/#/c/533/ ?

jonathanlevi
2016-08-17 08:18
Yes. We are on it... and if we can't fix it soon, at a last-resort, we'll revert items as needed. Just a heads-up.

jonathanlevi
2016-08-17 08:19
AFAICT, it's a combination of two changesets that worked separately. Just letting you know as you might see other failures that are not related to stuff you are working on.

bgorman
2016-08-17 08:19
does 533 not fix the issue?

jonathanlevi
2016-08-17 08:20
The build for 533 is running as we 'type'

bgorman
2016-08-17 08:20
ok, fair enough :slightly_smiling_face:

jonathanlevi
2016-08-17 08:20
The failure is in the BDDs, I'm staying up until we get it sorted.

jonathanlevi
2016-08-17 08:21
(that is, it takes time for a SUCCESS/FAILURE to pop-up)

ry
2016-08-17 08:21
Those BVTs are so long

bgorman
2016-08-17 08:22
well I hope @jcarrivick's fix works, he has been working to speed up all of the tests (which is what led to this)

jonathanlevi
2016-08-17 08:26
Same here @bgorman. We are in touch and we'll work it out, one way or another. I/we can always revert back to a stable `master`. Let's give it a round (or two) of testing...

jonathanlevi
2016-08-17 08:30
[For the "interested readers" out there: https://gerrit.hyperledger.org/r/#/c/421]

hgabor
2016-08-17 08:31
@bgorman: I am back and checking your Gerrit changeset.

hgabor
2016-08-17 08:34
@bgorman gerrit says it does not exist

ry
2016-08-17 08:38
@hgabor: I think it is published as draft

hgabor
2016-08-17 08:53
this is the link: https://gerrit.hyperledger.org/r/#/c/531/ but Gerrit says 'Code review - error'

gennady.laventman
2016-08-17 09:24
@simon, @muralisr : I just submitted the stream flow control change I told last week. Can somebody review it?

gennady.laventman
2016-08-17 09:25

hgabor
2016-08-17 09:30
I will have a look (in an hour)

gennady.laventman
2016-08-17 09:37
I opened JIRA issue for it as well: https://jira.hyperledger.org/browse/FAB-38

hgabor
2016-08-17 10:16
@ry: @jonathanlevi tried to revert a commit and we got an internal server error

garisingh
2016-08-17 10:55
has joined #fabric-dev

yacovm
2016-08-17 14:03
when I submit a gerrit review, the Signed-Off by is now automatically generated (in the commit message)?

hgabor
2016-08-17 14:03
no

hgabor
2016-08-17 14:03
git commit -s -m "Some commit message"

hgabor
2016-08-17 14:03
that -s does it

hgabor
2016-08-17 14:03
@yacovm

yacovm
2016-08-17 14:03
thanks!

yacovm
2016-08-17 14:04
I somehow thought the git review adds that

hgabor
2016-08-17 14:04
no, that is added locally and manually and with git

hgabor
2016-08-17 14:04
maybe git-review does something similar but I do not know that tool

muralisr
2016-08-17 14:04
@gennady.laventman: sure, will review

hgabor
2016-08-17 14:07
this commit needs to be reverted: https://gerrit.hyperledger.org/r/#/c/421 @jcarrivick created a fix but as I know (from @jonathanlevi ) it did not work. but we were unable to revert it, we got an internal server error.

hgabor
2016-08-17 14:07
sorry for repeating myself again and again but in the morning, @jonathanlevi informed me that master fails the tests

ghaskins
2016-08-17 14:24
@hgabor: worst case, I would image someone could do a “git revert && git push” and treat it as a new change set

hgabor
2016-08-17 14:25
@ghaskins: I will do that, you are right - I missed again the trivial solution. :slightly_smiling_face: But it would be good to have a working revert button. :slightly_smiling_face:

hgabor
2016-08-17 14:39
maybe this: https://gerrit.hyperledger.org/r/#/c/553/ @jcarrivick @jonathanlevi

yaoguo
2016-08-17 16:59
How can i re-trigger jenkins build in gerrit? reply with "recheck"?

ramesh
2016-08-17 16:59
try with reverify

yaoguo
2016-08-17 17:00
thanks

ry
2016-08-17 18:53
I don’t think we have those comment triggers set up

ry
2016-08-17 18:54
oh, I guess we do

jcarrivick
2016-08-17 23:54
Sorry all for the chaos I caused, I hope it didn't cause too much stress for those involved.

jonathanlevi
2016-08-18 00:37
@jcarrivick come on, we are in this business because we like the stress.

jcarrivick
2016-08-18 00:38
touche :slightly_smiling_face:

jcarrivick
2016-08-18 00:38
It could have been worse, it could have been a production box

jonathanlevi
2016-08-18 00:38
I don't think it was your thing per-se. We have to fix FAB-5 and make sure that our builds a `lot more` deterministic.

jonathanlevi
2016-08-18 00:38
If not 100%...

jonathanlevi
2016-08-18 00:39
Let's put it this way, I tend to be more permissive in your attempts to improve and shorter the build-time, because the benefits are huge. We wait so much for builds, and need much shorter cycles.

jonathanlevi
2016-08-18 00:41
At the same time, it's difficult to make the right call, late at night, when 3 build triggers give us 3 different results... but I guess the way to Mordor is full of ... and pain :wink:

jonathanlevi
2016-08-18 00:42
That said, I'm not sure I want to be Frodo :wink:

ry
2016-08-18 00:44
What is the long pole in the build?

ry
2016-08-18 00:45
Last night it looked like Geg behave tests were ~18 minutes IIRC

ramesh
2016-08-18 01:19
Unit tests are taking around ~25-30 mins and functional tests (behave) ~18 mins

ry
2016-08-18 01:24
is there any reason to not have two jobs?

ry
2016-08-18 01:24
I guess it would only save ~18 minutes overall

ry
2016-08-18 01:40
ramesh: it was something in the upgraded docker image that caused the hang. I’ve reverted to the previous image.

ghaskins
2016-08-18 01:43
@ry: wondering if you can sort out something for me

ry
2016-08-18 01:44
ghaskins: I will try

ghaskins
2016-08-18 01:44
I am noticing that certain bug reports have my old address attached to them somehow

ghaskins
2016-08-18 01:44
not sure where that is coming from

ry
2016-08-18 01:44
example?


ghaskins
2016-08-18 01:44
note in the reviewer list: there is “Greg Haskins” and “Gregory Haskins"

ghaskins
2016-08-18 01:44
its the Gregory one that seems to be attached to my old email

ry
2016-08-18 01:45
when was the last time that you used that address with this project? ever?

ghaskins
2016-08-18 01:45
heh, never

ghaskins
2016-08-18 01:45
its been almost 5 years since I worked tere

ghaskins
2016-08-18 01:45
there

ry
2016-08-18 01:45
did you ever use it on any other LF project?

ghaskins
2016-08-18 01:45
i am assuming it is some vestige of my LFID

ry
2016-08-18 01:46
your former LFID?

ghaskins
2016-08-18 01:46
im sure I did, I did a ton of kernel work with that address

ghaskins
2016-08-18 01:46
not sure, remember how I had that problem logging in and you helped me straighten it out

ghaskins
2016-08-18 01:47
i am assuming some how the email got attached/merged/whatever

ghaskins
2016-08-18 01:47
I just dont know where that is even coming from

ry
2016-08-18 01:47
interesting.

ghaskins
2016-08-18 01:48
Maybe Patrick explicitly added that reviewer list

ry
2016-08-18 01:48
I suspect the hackfest was… three weeks 22 hours ago? :slightly_smiling_face:

jonathanlevi
2016-08-18 01:48
LOL :wink:

jonathanlevi
2016-08-18 01:48
A pseudo-random guess, I'd guess.

ghaskins
2016-08-18 01:49
seems reasonable, though I wasnt able to attend that

ry
2016-08-18 01:49
oh, hmm. My next guess is you have it associated with an openID (github? facebook?) and you logged in with it

ghaskins
2016-08-18 01:49
its got to be something like that

ghaskins
2016-08-18 01:49
let me look at my LFID setup

bgorman
2016-08-18 01:50
@hgabor oops sorry... didn't realise drafts weren't publicly viewable... now I'm wondering what the point of drafts are

bgorman
2016-08-18 01:52
I guess I should have added you as a reviewer to let you see it

ry
2016-08-18 01:57
bgorman: I think if you add other people they can see it.

bgorman
2016-08-18 01:58
@ry are you able to view https://gerrit.hyperledger.org/r/#/c/531/ now?

ry
2016-08-18 01:59
bgorman: yes I am

bgorman
2016-08-18 01:59
cool, thanks. Mystery solved :slightly_smiling_face:

ry
2016-08-18 05:03
Most pending changes on Gerrit will need rebased to the tip of master

hgabor
2016-08-18 07:18
https://gerrit.hyperledger.org/r/#/c/551/ some easy-to-review changeset

satheesh
2016-08-18 07:24
Hi @hgabor , I am trying to rebase your changes from https://gerrit.hyperledger.org/r/#/c/317/ into mine, and its pending review at https://gerrit.hyperledger.org/r/#/c/415/

hgabor
2016-08-18 07:25
do you do it locally?

satheesh
2016-08-18 07:25
As part of this change, I am removing the duplicated chaincode.proto file inside the java-shim.

satheesh
2016-08-18 07:26
When looking at your change @ c-317, the chaincode.proto is slightly different.



satheesh
2016-08-18 07:26
`message ChaincodeInput { repeated bytes args = 1; }`

satheesh
2016-08-18 07:28
the file under java shim has `repeated bytes args = 2;`

satheesh
2016-08-18 07:28
Is there a specific reason ?

satheesh
2016-08-18 07:30
When I am trying to build with `repeated bytes args = 1;`, the java layer parses the message payload to get an empty argsList. However it works fine if I leave the field number to 2.

satheesh
2016-08-18 07:32
@hgabor: Yes, I am doing it locally to update my gerrit request

satheesh
2016-08-18 07:33
Since it cant be merged as it is.

hgabor
2016-08-18 07:33
the two files should be the same. I left them with "= 2" but Sheehan corrected it. But it seems that she forgot to correct the java one

bgorman
2016-08-18 07:37
hmm... I wonder if I'm going to fall afoul of that Java stuff with my REST changes (I regenerated the protos)

hgabor
2016-08-18 07:38
@bgorman: how would you?

bgorman
2016-08-18 07:38
regenerating the protos changes that 2 to a 1

bgorman
2016-08-18 07:38
I didn't see any Java code get updated either

hgabor
2016-08-18 07:39
I dont think that if the only field is args and one has changed the field number from 2 to 1 then that would induce any code change

bgorman
2016-08-18 07:42
that is not what @satheesh is describing

bgorman
2016-08-18 07:42
I'll find out soon enough though.... whenever these tests pass/fail .... /yawn

satheesh
2016-08-18 07:49
@bgorman, In the current master branch, chaincode.proto is duplicated. Also you might want to remove the generated java class Chaincode.java

bgorman
2016-08-18 07:50
really? crap $ find . -name chaincode.proto ./core/chaincode/shim/chaincode.proto ./core/chaincode/shim/java/src/main/proto/chaincode.proto ./protos/chaincode.proto ./sdk/node/lib/protos/chaincode.proto

satheesh
2016-08-18 07:51
In current gradle build, the build doesn't detect a change in proto file, and regenerate the .java files from .proto. I am modifying this in the change 415, to force copy .proto file and regenerate the .java files

satheesh
2016-08-18 07:51
`./protos/chaincode.proto` and `./core/chaincode/shim/java/src/main/proto/chaincode.proto` should be same

satheesh
2016-08-18 07:52
if you change `./core/chaincode/shim/java/src/main/proto/chaincode.proto`, remove these these files Chaincode.java, ChaincodeSupportGrpc.java and Chaincodeevent.java

bgorman
2016-08-18 07:52
I might just leave all that alone... I changed the protos purely for the rest interface's benefit, it should have no impact on Java

hgabor
2016-08-18 07:54
just a sidenote: I suggested to remove all the generated files (java and go). this way we could have build steps to: 1) distribute the protos to all directories where they are needed (copy from /protos to java/protos) 2) generate sources

satheesh
2016-08-18 07:59
I agree with @hgabor, we should remove generated files.

hgabor
2016-08-18 08:00
the others said that those files were added because the initial build system was unable to generate them

hgabor
2016-08-18 08:00
but as I know make is

hgabor
2016-08-18 08:01
and we could use gradle instead of make :stuck_out_tongue:

bgorman
2016-08-18 08:04
make can copy files as needed :stuck_out_tongue:

bgorman
2016-08-18 08:05
b: a cp a b

hgabor
2016-08-18 08:19
yes I know but it is generally considered hard to write good Makefiles

satheesh
2016-08-18 08:20
@hgabor: Now I know why it didn't work. chaincode.pb.go was not generated again after changing the field number

satheesh
2016-08-18 08:20
:relaxed:

hgabor
2016-08-18 08:20
as I remember, Sheehan submitted a patch for that

hgabor
2016-08-18 08:21
isnt it merged?

satheesh
2016-08-18 08:21

hgabor
2016-08-18 08:25
okay I will try to take care of that

hgabor
2016-08-18 08:25
to merge it

hgabor
2016-08-18 10:06
https://jenkins.hyperledger.org/job/fabric-verify-x86_64/406/console - locally, the commit works, no error in the unit tests...

satheesh
2016-08-18 10:43
@hgabor: Looks like a transient error not being able to download jar, you might want to retrigger the jenkins job

hgabor
2016-08-18 10:46
yes, thanks :slightly_smiling_face: I retrigger it

hgabor
2016-08-18 11:09
REST API related question: as you know, REST API needs base64 strings as arguments since https://gerrit.hyperledger.org/r/#/c/317/ got reviewed and merged But the users do not know about this (no docs tell them). To solve this ASAP: we have to 1) merge those docs https://gerrit.hyperledger.org/r/#/c/499/ 2) workaround rest api to use string as it used to https://gerrit.hyperledger.org/r/#/c/531/ @sheehan @cbf @simon @muralisr


cbf
2016-08-18 12:39
@hgabor: 531 needs to be rebased before it can be merged. 499 should be changed to reflect 531.

hgabor
2016-08-18 12:50
531 breaks some tests, I am working on it

hgabor
2016-08-18 12:50
@cbf

garisingh
2016-08-18 12:55
how about release notes rather than mailing lists?

garisingh
2016-08-18 12:55
:wink:

garisingh
2016-08-18 12:55
or let's tag things before we break them :wink:

garisingh
2016-08-18 12:56
I'll be honest - as someone who simply wants to use this stuff, I don't want to follow mailing lists

garisingh
2016-08-18 12:56
(well if I was someone who simply wanted to use the stuff :wink: )

garisingh
2016-08-18 12:57
we should probably just keep people who really want to build apps today on the v0.5 preview

hgabor
2016-08-18 13:20
@garisingh: I think tags+release notes is a good idea. on the other side, we should have the mailing list + something that announces new mails here

garisingh
2016-08-18 13:22
agreed

cbf
2016-08-18 13:34
then we actually need to be doing releases - this would be my preference, TBH rather than once a quarter we should be cutting stable releases frequently and getting into a groove

cbf
2016-08-18 13:35
however, summertime, is challenging though to get decisions made

garisingh
2016-08-18 13:38
@cbf - sure. so I guess in the short term, if we make breaking changes in master, people will be at risk of their applications breaking - which is probably OK given that it is master and then are living on the edge. But then that means we need a way to point people to the "stable" releases and at this point the only "stable" release is v0.5

garisingh
2016-08-18 13:40
maybe this is not the right place for this, but I also notice that a lot of people who simply want to build chaincode and apps are struggling trying to get environments running. They really should not ever have to build / compile anything. We need a way to point them to using the correct Docker images. Just my not-so-humble opinion

garisingh
2016-08-18 13:40
(or course they can all just go use our BMX service too :wink: )

cbf
2016-08-18 13:45
@garisingh: agreed, and I am working on a chaincode development image that people can just use

cbf
2016-08-18 13:45
and I think we want to be more formally embracing chaintool @ghaskins

garisingh
2016-08-18 13:48
I do not think I can endorse any @ghaskins created work. haha - just kidding

ghaskins
2016-08-18 13:48
doh!

garisingh
2016-08-18 13:49
(I need to entertain myself sometimes - sorry)

ghaskins
2016-08-18 13:49
heh

hgabor
2016-08-18 13:49
:smile:

baohua
2016-08-18 14:43
@cbf: About the dev image, do u mean vm or Docker? For the latter, would like to offer a hand :slightly_smiling_face:

ghaskins
2016-08-19 03:14

ghaskins
2016-08-19 03:15
i started to tackle some of the shortcomings with versioning…though its still WIP for now

ghaskins
2016-08-19 03:15
but wanted to get your thoughts

ghaskins
2016-08-19 03:15
I marked it with a -1 so its not going to get merged by accident

grapebaba
2016-08-19 07:03
where is 0.5 branch now? still github?

baohua
2016-08-19 07:36
i guess so

garisingh
2016-08-19 08:07
@grapebaba: correct. the 0.5 branch is frozen in the "old" github repo

grapebaba
2016-08-19 08:39
thanks, guys

hgabor
2016-08-19 08:49
could anybody help me with this? https://gerrit.hyperledger.org/r/#/c/567/ I mean the failing tests

garisingh
2016-08-19 09:05
@hgabor: does this line pass in unit tests `ctorbytes, merr := asn1.Marshal(chaincodeInvocationSpec.ChaincodeSpec.CtorMsg)` ?

hgabor
2016-08-19 09:06
locally it passed them

garisingh
2016-08-19 09:06
shouldn't you be marshaling the args ?

hgabor
2016-08-19 09:06
I marshall all the ctormsg

yaoguo
2016-08-19 09:06
Same problem.

hgabor
2016-08-19 09:06
which is ChaincodeInput{ Args :: [][]byte }

garisingh
2016-08-19 09:07
right. but how would the asn1 encoder know how to marshal / unmarshal protobufs? maybe I am just missing something (so sorry if I am)

garisingh
2016-08-19 09:08
I am looking at the error `Assertion Failed: Failed to POST to http://172.17.0.37:7050/devops/invoke: {"Error": "Error marshalling constructor: asn1: structure error: unknown Go type: *protos.ChaincodeInput"}`

hgabor
2016-08-19 09:08
ChaincodeInput is just a go struct. maybe I missed something but for me it seemed that Go's ASN1 can marshal any Go interface

hgabor
2016-08-19 09:09
but you may be right if it is really there, the error

hgabor
2016-08-19 09:09
ooh


hgabor
2016-08-19 09:11
btw this fails on master (for me at least): peer_basic.feature:896 chaincode example02 with 4 peers and 1 membersrvc, test crash fault -- @1.1 Consensus Options


hgabor
2016-08-19 09:19
Shouldn't that have made other tests even unit tests fail?

simon
2016-08-19 09:22
hgabor: you can't marshal pointers, just embedded structs

garisingh
2016-08-19 09:23
maybe not since it looks like that is only hit if you set the customIDgenAlg flag

hgabor
2016-08-19 09:29
Oh right

hgabor
2016-08-19 09:44
Is it enough to just dereference it?

ghaskins
2016-08-19 13:24
@simon: https://gerrit.hyperledger.org/r/#/c/571/ I took your advice about the relationship of the binary version to yaml and removed it

ghaskins
2016-08-19 13:24
its baked into the binary now, which I think is the right direction

ghaskins
2016-08-19 13:24
let me know your thoughts on that patch

harrijk
2016-08-19 13:29
has joined #fabric-dev

satheesh
2016-08-19 17:52
Submitted the https://gerrit.hyperledger.org/r/#/c/415/ after rebasing with master again since new commits caused merge conflict.

adrianclv
2016-08-19 20:30
has joined #fabric-dev

kell
2016-08-20 15:39
has joined #fabric-dev

yacovm
2016-08-21 08:43
Anyone on?

garisingh
2016-08-21 11:53
depends :wink:

jonathanlevi
2016-08-21 18:12
Good morning/afternoon/evening, @tamas, @ghaskins, @sheehan, et al., can we give https://gerrit.hyperledger.org/r/#/c/455/ some love?

jonathanlevi
2016-08-21 18:13
We need to get the sdk/node tests running as part of the cycle (there are related issues that depend on it)

ry
2016-08-21 22:32
@jonathanlevi: please update the commit message and re-add @hgabor 's sign off on the line above yours. I know it's persnickety but that's how the attribution works

jcarrivick
2016-08-22 05:39
So the certificates used for TLS in the BDD tests have expired

jcarrivick
2016-08-22 05:39
Does anyone know how to generate new ones or ignore certificate errors in the peers?

jonathanlevi
2016-08-22 05:59
Yes, but btw, I am bout to remove these.

jonathanlevi
2016-08-22 05:59
These are generated by the TLSCA... I have an issue open that I'm about to update.

jonathanlevi
2016-08-22 06:00
@jcarrivick ^^^

yaoguo
2016-08-22 06:05
When i upload commit to gerrit by "git-review" or "git push origin refs/for/master", it returns "you are not allowed to upload merges". Does anyone knows the problem?

jonathanlevi
2016-08-22 06:11
@yauguo: `git review -R` ?

jonathanlevi
2016-08-22 06:12
@jcarrivick: as discussed directly, go ahead with your other changes regardless of the TLS test.

jonathanlevi
2016-08-22 06:12
We can pair on FAB-213 or so.

yaoguo
2016-08-22 06:39
@jonathanlevi Not work. It should work before this week.

ry
2016-08-22 06:50
@yaoguo: 'git push origin HEAD:refs/for/master' doesn't work?

ry
2016-08-22 06:50
Oh, you have a merge.

ry
2016-08-22 06:50
git rebase -i origin/master

ry
2016-08-22 06:51
You aren't allowed (nobody is) to push merges

ry
2016-08-22 06:52
It sounds like you made a change and then did a git pull from master, which made a merge commit

ry
2016-08-22 06:55
Anyway, something like git reset HEAD~ && git fetch origin master && git rebase -i FETCH_HEAD && git push ... should get you there. You will need to git reset to your change (git log -1 shows just your change)

ry
2016-08-22 06:56
This is close, I cannot test the commands on my iPad

yaoguo
2016-08-22 06:56
@ry Thanks. You're right. I did a git pull and tried to rebase my branch before upload.

ry
2016-08-22 06:57
So you're almost there

ry
2016-08-22 06:58
You'll obviously need to fetch and rebase on the right branch.

yaoguo
2016-08-22 06:58
"git rebase -i origin/master" works.

yaoguo
2016-08-22 06:59
Thanks again.

ry
2016-08-22 06:59
Ok, and git log shows the change you want at the tip?

ry
2016-08-22 06:59
You're very welcome

yaoguo
2016-08-22 07:00
Yes. And push to gerrit successfully.

yacovm
2016-08-22 07:38
who's "responsible" for the java shim?

yacovm
2016-08-22 07:38
(Who can i consult with, regarding the gradle file in the java shim)

ry
2016-08-22 07:39
Which file exactly?

yacovm
2016-08-22 07:39
the gradle config file

yacovm
2016-08-22 07:40
core/chaincode/shim/java/build.gradle

ry
2016-08-22 07:40
it looks like @hgabor was the last person to modify it

yacovm
2016-08-22 07:41
I'm doing the JIRA issue that involves upgrading the protobuf version from the version we have to the latest, and I was wondering if it needs to be changed too to accommodate possible changes in the go generated pb.go files (i hope not)

ry
2016-08-22 07:42
it looks like wrote it, but I don’t know their handle in here

yacovm
2016-08-22 07:42
ok thanks

hgabor
2016-08-22 07:48
what did I do? :slightly_smiling_face:

yacovm
2016-08-22 07:53
com.google.protobuf:protoc:3.0.0-beta-2

yacovm
2016-08-22 07:53
you have any idea if this needs to be upgraded?

yacovm
2016-08-22 07:53
if I'm upgrading the protobuf pb.go files to version 3 not-beta?

hgabor
2016-08-22 08:01
no clue. wait I will have a look at that gradle file

hgabor
2016-08-22 08:02
I guess it needs

hgabor
2016-08-22 08:03
but that change means upgrade for the "go-side" protobuf, right?

yacovm
2016-08-22 08:04
I'm upgrading the go-side and I'm asking what (if any) change do i need to do to the java side (the "java shim" tests passed (*I think*) ). Does java create a descriptor how to serialize the protobuf entities in runtime? (i think it does)

yacovm
2016-08-22 08:06
My assumption is that if any change will be needed, it's only to up the version in the gradle file

hgabor
2016-08-22 08:06
I think your assumption is right. (but I am not really an expert of this)

hgabor
2016-08-22 08:07
if you up that version in that gradle, it will download a newer gradle and use that

hgabor
2016-08-22 08:07
afaik

jlamiel
2016-08-22 08:30
has joined #fabric-dev

grapebaba
2016-08-22 08:39
--- FAIL: TestChaincodeInvokeChaincode (43.12s) exectransaction_test.go:800: TestChaincodeInvokeChaincode starting db_test_exports.go:47: Creating testDB exectransaction_test.go:854: deployed chaincode_example02 got cID1:path:"http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" name:"b4b3a128ae54cb216bc979789a10da53e3f779fe1a6491f7f6bc983a42f3e0d57ab85c15589c632fbd3df3c7ff6d8c5bb5b48acec70cb231c9ca4b4d6d83c235" , chaincodeID1:b4b3a128ae54cb216bc979789a10da53e3f779fe1a6491f7f6bc983a42f3e0d57ab85c15589c632fbd3df3c7ff6d8c5bb5b48acec70cb231c9ca4b4d6d83c235 exectransaction_test.go:891: Error invoking <579dd137665f544d367e6ff9822fd1fce3ce31cfe7d6962788da37e13eb44db882dd3b03b38c10192e5e5550f37319e5ccaa2d031ddc7280e2226c5703c5a187>: Transaction or query returned with failure: [70512126-ad09-41a1-86c7-7b453f690147]Chaincode handler FSM cannot handle message (ERROR) with payload size (269) while in state: ready 08:27:02.804 [chaincode] NewChaincodeSupport -> INFO 024 Chaincode support using peerAddress: 0.0.0.0:21212 getting deployment spec for chaincode spec: type:GOLANG chaincodeID:<path:"github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" > ctorMsg:<args:"init" args:"a" args:"100" args:"b" args:"200" > 08:27:02.810 [container] WriteGopathSrc -> INFO 025 rootDirectory = /opt/gopath/src getting deployment spec for chaincode spec: type:GOLANG chaincodeID:<path:"github.com/hyperledger/fabric/examples/chaincode/go/passthru" > ctorMsg:<args:"init" > 08:27:19.503 [container] WriteGopathSrc -> INFO 026 rootDirectory = /opt/gopath/src 08:27:43.652 [chaincode] processStream -> ERRO 027 Got error: Incorrect number of arguments. Expecting 3 08:27:43.653 [chaincode] processStream -> ERRO 028 Got error: Incorrect number of arguments. Expecting 3 08:27:43.668 [chaincode] processStream -> ERRO 029 Error handling chaincode support stream: connection error: desc = "transport is closing" 08:27:43.752 [chaincode] processStream -> ERRO 02a Error handling chaincode support stream: connection error: desc = "transport is closing"

grapebaba
2016-08-22 08:39
anyone meet this error with latest code?

hgabor
2016-08-22 08:40
@grapebaba I always meet this

hgabor
2016-08-22 08:42
there is a file: core/container/dockercontroller/dockercontroller.go could you modigy its 235th line from !dontremove to false (we do not want to remove the container for testing), rebuild peer and peer-image and then rerun just this unit test (cd into core/chaincode and run go test -run "TestChaincodeInvoke") and send me the container logs? (docker ps and then you will find some recent containers there)

hgabor
2016-08-22 08:44
for me, the problem used to be that there is a hash in chaincode_example04 which is for chaincode_example02. and it usually changes (no clue how, maybe if you change something that is needed for the build of chaincode_example01 then the binary is changed and the hash is changed too)

hgabor
2016-08-22 08:52
docker ps -a is the right command as the containers will be stopped but not deleted

grapebaba
2016-08-22 08:55
maybe

grapebaba
2016-08-22 08:55
i met this first time

grapebaba
2016-08-22 08:55
i remember i delete three chaincode binary

hgabor
2016-08-22 08:55
yes and this is the way you can debug it :slightly_smiling_face: if you find something like: could not get deploy transaction for... then it is surely the hash problem I told

hgabor
2016-08-22 08:56
I mean if you find that in the logs somewhere

ry
2016-08-22 08:57
protip: if you’re pasting a bunch of text, click the + next to the text box, and upload it as a snippet. it lets people expand and contract it, and copy/paste it without formatting changes

grapebaba
2016-08-22 08:58
thanks @ry


yacovm
2016-08-22 09:40
I got this error message this week

grapebaba
2016-08-22 09:41
why it passed on jenkins

hgabor
2016-08-22 09:43
@grapebaba is it possible that you have unneeded files (e.g. junk) in chaincode directories?

grapebaba
2016-08-22 09:43
no

grapebaba
2016-08-22 09:45
oh wait

grapebaba
2016-08-22 10:14
@hgabor I pull the latest code and checkout master

grapebaba
2016-08-22 10:14
still that error

hgabor
2016-08-22 10:14
then the hash is simply erroneous on master

grapebaba
2016-08-22 10:15
but why i don't see error on jenkins?

grapebaba
2016-08-22 10:16
does it exist in your local?

grapebaba
2016-08-22 10:18
i have to go back, i will investigate per your instruction

hgabor
2016-08-22 10:33
@grapebaba If it does not exit on Jenkins then there must be something locally. Maybe git clean could help. Last time for me it was some temporary editor file.

hgabor
2016-08-22 10:33
@grapebaba A bit later, I will check my local for you.

gennady.laventman
2016-08-22 10:34
@hgabor , @muralisr : Any chance for https://gerrit.hyperledger.org/r/#/c/535/?

hgabor
2016-08-22 10:37
@gennady.laventman Sorry I have not had time for reviews yet

hgabor
2016-08-22 10:37
but I will check it, no worries :slightly_smiling_face:

gennady.laventman
2016-08-22 10:38
I even rebased it, to contain last week changes :slightly_smiling_face:

gennady.laventman
2016-08-22 10:42
What happens with bdd tests? For example, I got this on jenkins:

gennady.laventman
2016-08-22 10:42

gennady.laventman
2016-08-22 10:43
But same test runs fine locally: behave -k -t issue_2116

hgabor
2016-08-22 10:48
isn't that an unstable one?

gennady.laventman
2016-08-22 10:52
It failed (for me) on jenkins, but pass fine (multiple times) localy

yacovm
2016-08-22 11:10
@hgabor I think it wasn't needed in the end, somehow all the tests (unit tests + BDD) pass, so unless there are no tests that include java code sending gRPC messages to go code, i think it works

hgabor
2016-08-22 11:11
yes, but that means that go uses some different protobuf from Java

yacovm
2016-08-22 11:25
Not necessarily, it might mean that the entities we send via gRPC/v3 can be successfully deserialized by v3-beta protobuf, maybe v3 supports stuff that v3beta doesn't, but we don't use it, or- maybe the difference between v3 and v3-beta is only in the generated code and not in the format or something

hgabor
2016-08-22 11:29
yeah yeah I see this. :slightly_smiling_face: for me, it is OK if we leave it this way, but I prefer using a newer protobuf for Java if we use a newer for Go. just to keep them in sync

csehd
2016-08-22 12:40
has joined #fabric-dev

grapebaba
2016-08-22 12:45
@hgabor: did you check your local yet?

hgabor
2016-08-22 12:56
@grapebaba just checked and it seems to fail on master

hgabor
2016-08-22 12:58
I can fix it on master

muralisr
2016-08-22 13:09
@gennady.laventman: will review today/tonight

gennady.laventman
2016-08-22 13:13
@muralisr : @hgabor did it for me 1 hour ago, but the more the merrier :slightly_smiling_face:

muralisr
2016-08-22 13:14
ah ok

muralisr
2016-08-22 13:14
will still take a look at it … wanted to understand rationale etc

hgabor
2016-08-22 13:15
@muralisr could you read back a little bit? @grapebaba has some problems (and me too) with the hash in exaple04 on master

hgabor
2016-08-22 13:32

hgabor
2016-08-22 13:32
I have done the some for https://gerrit.hyperledger.org/r/#/c/531/ but it does not work

hgabor
2016-08-22 13:32
locally it was ok, I did git clean

gennady.laventman
2016-08-22 13:44
@muralisr : You welcome :slightly_smiling_face:

muralisr
2016-08-22 13:45
@hgabor: reading...

muralisr
2016-08-22 13:46
@hgabor: @grapebaba sounds like init failed with invalid args

muralisr
2016-08-22 13:47
@hgabor argument conversion issue in the chaincode-chaincode path ?

hgabor
2016-08-22 13:49
@muralisr I checked out master and for me it seemed as hash issue but maybe my workspace was messy

hgabor
2016-08-22 13:49
I will check again

hgabor
2016-08-22 13:52
it does not work on master

ry
2016-08-22 16:28
@binhn: It’s easy for me to create a branch, I was waiting for consensus on the name before I do anything. Give me a name and I’ll make it

ry
2016-08-22 16:28
@arnaud @cbf ^^^

jonathanlevi
2016-08-22 16:42
@binhn, @ry: I’m fine with a dev or integration branch, btw. I suggested it a few times before (especially for integration)

jonathanlevi
2016-08-22 16:43
E.g., the Membership Services <-> ClientSDK work in v0.5

jonathanlevi
2016-08-22 16:43
I’ll reply more formally once I ‘get my bearings'

jonathanlevi
2016-08-22 16:43
I, too, don’t mind its name, or so.

jonathanlevi
2016-08-22 16:44
The main concern is probably that such ‘feature’ branches would diverge too much… [EDIT: I should have probably phrased this as a question: “is the main concern with development/feature/integration branches… X, Y, Z”?]

ry
2016-08-22 16:44
@jonathanlevi branches are cheap, I really don’t care too much if people want them. Having dozens of them does clutter the UI.

ry
2016-08-22 16:44
@jonathanlevi I’m not _too_ worried about divergence, because that’s on the branch maintainer to handle.

jonathanlevi
2016-08-22 16:44
(Yes, I appreciate this @ry !)

ry
2016-08-22 16:45
@jonathanlevi you should be merging from master (or whatever) every once in a while

cbf
2016-08-22 16:51
feature branches don’t diverge if they regularly rebase on master

jonathanlevi
2016-08-22 17:29
Yup, moreover, maintainers should be able to set some ‘merge up’ schedule as part of the sprints. Independently, individually (with much managerial head-ache/overhead)… but if people tell us, “hey, 2 sprints of full-time work of 3 teams are about to get merged up this Thu…” then people are aware of it.

jonathanlevi
2016-08-22 17:29
Again, leaving it to the ‘feature branch maintainer etc.’… but yes: `merging down` from master into the integration branch frequently and `merging up` to master regularly (relatively often enough) keeps both the f branch and m, in sync.

jonathanlevi
2016-08-22 17:30
As I said before (also on the day we moved to gerrit, if some of you recall), I like branches.

binhn
2016-08-22 17:57
@ry i don’t really have a good name, how about ‘convergence’ ?

ry
2016-08-22 17:58
from the tip of master?

binhn
2016-08-22 17:59
yes


binhn
2016-08-22 18:00
thank you!

ghaskins
2016-08-22 20:22
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F23QHKF3K/-.sh and commented: @cbf

jonathanlevi
2016-08-22 21:26
@ghaskins: :+1::+1::+1::+1:

jonathanlevi
2016-08-22 21:27
== 4x (+1) == 4 == 2x (+2) most likely !

gentrysherrill
2016-08-22 23:38
has joined #fabric-dev

jonathanlevi
2016-08-23 03:08
Hi @jcarrivick: now that it’s a working day here… we should at the very least update the certificate here in: https://jira.hyperledger.org/browse/FAB-213

jonathanlevi
2016-08-23 03:08
(it was Sunday evening, locally/yesterday)

jcarrivick
2016-08-23 03:10
Of course! So sorry, I should have realised it was a Sunday for you yesterday!

jonathanlevi
2016-08-23 03:10
See the update on the issue - but since there are some talks around removing (some of) the TLSCA, or at the very least separating it out… I wouldn’t worry about it.

jonathanlevi
2016-08-23 03:10
Oh, no worries about it. On Mondays I’m way more likely to be in front of a computer :wink:

jcarrivick
2016-08-23 03:10
The one TLS test that is there was passing with the expired certificate, which you're right, is really bad

jonathanlevi
2016-08-23 03:11
Yes, that’s what I was `hinting` at.

jonathanlevi
2016-08-23 03:11
I can try to either quickly fix the test/update the cert, or really be a bit more pragmatic and remove the (sub-optimal) functionality. Let me run it by a few people tomorrow.

jcarrivick
2016-08-23 03:12
I only picked it up because change 563 checks to see what peers are connected to and that test failed because they we're connected to each other!

jcarrivick
2016-08-23 03:12
Yeah sure, I'll leave the tests disabled for now

jonathanlevi
2016-08-23 03:13
In general, I’m leaning towards: “If it’s part of our code base, it’s because it is: (`working` + `needed-to-be-there`)"

jonathanlevi
2016-08-23 03:14
Otherwise, we should not 1) carry it around, nor, 2) “mislead”/risk-confusing others that’d believe that it’s working.

jonathanlevi
2016-08-23 03:15
Thank you for reporting this!

jcarrivick
2016-08-23 03:16
I agree completely, but I'll leave the removing/updating that needs doing for another change

jcarrivick
2016-08-23 03:16
Not a problem!

jonathanlevi
2016-08-23 03:16
Yes, yes. Leave it with me. One q: does it block you today/tomorrow?

jcarrivick
2016-08-23 03:18
Not at all, I've just got https://gerrit.hyperledger.org/r/563 sitting open at the moment with the TLS tests disabled. If you're happy that goes in with them disabled, great, otherwise I'll leave a comment saying it shouldn't be merged until you've sorted it

jonathanlevi
2016-08-23 03:18
OK. Give me 24 hours.

jonathanlevi
2016-08-23 03:18
(thank you)

jcarrivick
2016-08-23 03:18
No problem!

hyperpiper
2016-08-23 03:44
has joined #fabric-dev

hgabor
2016-08-23 08:09

hgabor
2016-08-23 08:35

hgabor
2016-08-23 08:56
fabric/examples/chaincode/java/SimpleSample <--- this does not compile for me

satheesh
2016-08-23 09:17
@hgabor What is the error you get

hgabor
2016-08-23 09:20
I will write you the exact error message as soon as I get back to the office

hgabor
2016-08-23 09:22
@bfuentes: please help me out :-) you have the same problem

dave.enyeart
2016-08-23 16:44
has joined #fabric-dev

ry
2016-08-23 16:55
gentlefolk, the `two +2 merge rule` has been pushed for fabric. this rule obviated NACR (non-author code review) so it’s been removed. You may have noticed the UI changed. It isn’t in use on any other project (because nobody has asked for it)

ghaskins
2016-08-23 18:57
@ry, IIUC, you are saying 2+2 eclipsed NACR? Does that mean a submitter may propose their own +2 and it counts?

ghaskins
2016-08-23 18:58
also, is the 2+2 any +2, or only from maintainer list?

ry
2016-08-23 18:58
ghaskins: yes. NACR enforced a non-author code review, which didn’t prevent the author from reviewing a change

ry
2016-08-23 18:59
the only people that should be able to +2 a change are the committers for a project

ghaskins
2016-08-23 18:59
ah, ok, i didnt realize that

ghaskins
2016-08-23 18:59
so, in theory a submitter _could_ +2 their own patch iff they are a committer too

ry
2016-08-23 18:59
yes.

ghaskins
2016-08-23 19:00
i dont have a strong opinion on this, but it strikes me as more correct to have it be 2+2 from NA

ghaskins
2016-08-23 19:00
(the self +2 is implicit, or they wouldnt have submitted it

ry
2016-08-23 19:00
I’m not against it.

ghaskins
2016-08-23 19:01
but I guess I can see the argument that the committer has a vote too, even if its their own patch

ry
2016-08-23 19:01
I don’t think the self +2 _is_ implicit, always.

ghaskins
2016-08-23 19:01
well, no it isnt, you are correct

ghaskins
2016-08-23 19:02
anyway, something to think about, i dont think it matters too much unless we had the unlikely scenario of abuse

ghaskins
2016-08-23 19:02
it at least has the checks and balances that one other +2 is needed first

ry
2016-08-23 19:03
Sure. Right now it would require the collusion (or inattention) of one other committer to screw things up.

ghaskins
2016-08-23 19:03
anyway, thanks for that change, that will make things run smoother

ry
2016-08-23 19:03
sure thing.

yoshihara
2016-08-24 04:14
has joined #fabric-dev

hgabor
2016-08-24 07:39
@ry @ghaskins too much text to read. :smile: do we have double +2 policy now? If not (yet) I support it!

ry
2016-08-24 07:44
Yes

ry
2016-08-24 07:47
hgabor: what does the fabric-api group want? I left it with NACR enabled, and didn’t add the 2+2 policy

ry
2016-08-24 07:47
since the velocity is low and you are the only committer, I figured it was low risk

hgabor
2016-08-24 07:48
I think NACR is enough as there are only a few maintainters :slightly_smiling_face:

hgabor
2016-08-24 07:48
such a good thing that there is an edit button. I make a typo every second minute

ry
2016-08-24 07:48
eh, I don’t worry too much about typos here

hgabor
2016-08-24 09:29
Last part of @bgorman 's commit: https://gerrit.hyperledger.org/r/#/c/639/ @jonathanlevi @ghaskins @simon

grapebaba
2016-08-24 09:46
after i rebase latest master

grapebaba
2016-08-24 09:46
jenkins build failure

sergeybalashevich
2016-08-24 10:09
has joined #fabric-dev

grapebaba
2016-08-24 10:10
@ry

grapebaba
2016-08-24 10:11

jake.turner
2016-08-24 13:36
has joined #fabric-dev

david.acton
2016-08-24 14:02
Hi. I’ve been away for a few weeks. Can someone point me to some docs on why we moved to gerrit?! IMO this is a huge backward step.

hgabor
2016-08-24 14:08
@david.acton why would it be?

simon
2016-08-24 14:11
david.acton: linux foundation wanted it

david.acton
2016-08-24 15:40
@hgabor Because the rest of the world is on GitHub. Gerrit doesn’t have the integration with third parties (like read the docs) that GitHub has. I have two accounts rather than one account, and forking is lovely and hosted in GitHub, more manual in Gerrit. Like I said,, just my opinion.

david.acton
2016-08-24 15:41
@simon That’s a reason I guess.

david.acton
2016-08-24 15:41
@simon @hgabor Thanks both for replying!

hgabor
2016-08-24 16:00
@david.acton: having a good review gui on Gerrit does not mean that we have to leave github as a repo browser and a way to create forks,. Of course those cannot be merged back, but for things which need to land in the repo I think Gerrit is much cleaner

david.acton
2016-08-24 16:13
@hgabor good point. But there’s wisdom in those crowds. Lots of people are there for a reason. Where will the latest docs be now? Is there something like read the docs now?

hgabor
2016-08-24 16:14
As I was informed today we will begin mirroring to github and the doc reader things will work as they were before Gerrit

david.acton
2016-08-24 16:15
That’s good news.

troyronda
2016-08-24 16:19
Cool.

benbooth
2016-08-24 17:47
has joined #fabric-dev

benbooth
2016-08-24 19:12
Can anyone point me to the most up-to-date DEVENV documentation?

benbooth
2016-08-24 19:12
I'm developing on Mac with Docker (hopefully)!

benbooth
2016-08-24 19:13
Would love to get some peers up and running so I can start writing Chain Code


nikileshsa
2016-08-24 21:55
has joined #fabric-dev

pushpalatha
2016-08-25 06:57
has joined #fabric-dev


grapebaba
2016-08-27 11:04
@yacovm: is our gossip implementation refer to this paper?

benbooth
2016-08-27 11:10
Would raft be a potential fit for consensus between peers?

benbooth
2016-08-27 11:11

garisingh
2016-08-27 11:31
@benbooth - if your only requirement is crash fault tolerance and not byzantine fault tolerance than you could use Raft. There is also BFT Raft: http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf - and there is at least one public implementation of it

benbooth
2016-08-27 11:34
@garisingh Thanks...will have a read

yacovm
2016-08-27 16:08
@grapebaba My team is implementing a gossip implementation that disseminates messages from the consensus service to the rest of the peers. It has nothing to do with the paper you quoted.

nikileshsa
2016-08-27 18:19
@yacovm is there a specification for this gossip implementation you guys are working on?

yacovm
2016-08-27 18:53
yeah, the spec is a WIP itself though. @nikileshsa .

yacovm
2016-08-27 18:54
maybe it's a good time to upload the latest changes


nikileshsa
2016-08-27 19:44
@yacovm thanks.. will read

nikileshsa
2016-08-27 19:45
i see a pdf and an powerpoint attached in FAB-170

nikileshsa
2016-08-27 19:45
a ppt*

yacovm
2016-08-27 19:46
yep. The ppt is very high level, the pdf is a more low level. the markdown is the same as the pdf, so some day it'll go to github

nikileshsa
2016-08-27 19:46
oh ok.. got it! i am sure it must be an evolving document

yacovm
2016-08-27 19:49
if you have constructive comments, you can PM me

nikileshsa
2016-08-27 19:51
sure thing


yacovm
2016-08-27 19:56
well, that's something I can't help you with unfortunately

nikileshsa
2016-08-27 19:56
hmm.. trying to see if there a workaround..

yacovm
2016-08-27 19:57
You have a company server with good connectivity to the internet?

nikileshsa
2016-08-27 19:57
i am able to download the file from the node..

nikileshsa
2016-08-27 19:57
yeah..

nikileshsa
2016-08-27 19:57
i saw this issue before..and i suspected it would be because of some flaky internet issue

yacovm
2016-08-27 19:57
if you're running it on your PC I'd suggest to run the vagrant on some company server, they usually have better connectivity.

yacovm
2016-08-27 19:58
but let's not talk about it here, it's related to fabric-dev-env

nikileshsa
2016-08-27 19:59
sure. thanks.

nikileshsa
2016-08-27 20:00
will try posting in fabric-dev-env..

grapebaba
2016-08-27 23:43
@yacovm: thanks

muralisr
2016-08-28 15:44
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F25P4E62W/pasted_image_at_2016_08_28_11_42_am.png and commented: @ghaskins @cbf I was getting errors like above with latest. Getting latest protoc-gen-go and doing some cleanup fixed it. I’d have expected this to work without manual intervention….did I miss something ?

muralisr
2016-08-28 15:45
perhaps I should have done vagrant destroy first ?

hyperpiper
2016-08-28 16:23
@muralisr: there was actually an issue on gerrit to fix that problem apparently


muralisr
2016-08-28 16:24
ah ok. thanks

hyperpiper
2016-08-28 16:25
Out of curiosity because my build also fails with those errors :disappointed:, how did you manually fix it? There's just so much code going on in this repo and it's honestly hard for me to follow

muralisr
2016-08-28 16:26
here’s what I did

muralisr
2016-08-28 16:26

muralisr
2016-08-28 16:26
cd /opt/gopath/src/github.com/golang/protobuf/

muralisr
2016-08-28 16:27
make

muralisr
2016-08-28 16:27
cd fabric

muralisr
2016-08-28 16:27
cd protos

muralisr
2016-08-28 16:27
rm *.pb.go

muralisr
2016-08-28 16:27
cd ..

muralisr
2016-08-28 16:27
make protos

muralisr
2016-08-28 16:27
cd protos

muralisr
2016-08-28 16:27
go build

muralisr
2016-08-28 16:28
basically regen everything with correct protoc-gen-go

muralisr
2016-08-28 16:28
YMMV

muralisr
2016-08-28 16:29
but I’ll use the fix once its merged

hyperpiper
2016-08-28 16:30
Did you do the 'go get' command in the devenv folder?

muralisr
2016-08-28 16:30
I did it from home

muralisr
2016-08-28 16:30
let $GOPATH do the work

muralisr
2016-08-28 16:30
ie, did a “cd<return” first

hyperpiper
2016-08-28 16:31
Oh gotcha thank you!!!!!

muralisr
2016-08-28 16:31
will accept if it worked for you :wink:

hyperpiper
2016-08-28 16:32
Haha I'll try it soon and let you know if it works but I appreciate it either way

muralisr
2016-08-28 16:33
sure thing!

muralisr
2016-08-28 16:34
btw, I didn’t test yet. just made sure it built

muralisr
2016-08-28 16:34
wonder if this will have test issues

2016-08-29 03:40
@poly commented on @zuowang’s file https://hyperledgerproject.slack.com/files/zuowang/F1JAWEW1H/_____________20160617150935.png: Hi, how is it going here, have you got an answer yet? Im also curious about this.

kurokuro
2016-08-29 04:59
has joined #fabric-dev

grapebaba
2016-08-29 07:21
Look through the code, there are many config.go files and exist some duplicate code. I create a ticket https://jira.hyperledger.org/browse/FAB-260

grapebaba
2016-08-29 07:23
could we unify it? I found a comment mentioned a circular import issue for config, who know the context?

hgabor
2016-08-29 12:16
does anybody know TestHTTPExecuteDeployTransaction?

muralisr
2016-08-29 13:14
@hgabor what do you need ?

hgabor
2016-08-29 13:15
I am trying to change the chaincode api (feature/convergence) and that test fails

hgabor
2016-08-29 13:16
but the repo it uses it bgorman's one

muralisr
2016-08-29 13:16
how about upload to github another chaincode with the right api and point to it that way older tests will continue to work

rafael
2016-08-29 14:25
has joined #fabric-dev

hgabor
2016-08-29 14:41
when trying to run TestHTTPExecuteDeployTransaction, I get this: exectransaction_test.go:349: Error deploying <>: code does not exist Download failed open /opt/gopath/_usercode_/065860103/src/github.com/gabre/fabric/examples/chaincode/go/chai... (I uploaded a chaincode for TestHTTPExecuteDeployTransaction)

muralisr
2016-08-29 15:15
perhaps you have $GOPATH/src/github.com/gabre/fabric/examples/chaincode/go/chaincode/...

muralisr
2016-08-29 15:15
ie in your GOPATH ?

muralisr
2016-08-29 15:15
ls $GOPATH/src/github.com/gabre/fabric/examples/chaincode/go/chaincode


muralisr
2016-08-29 15:16
it would have downloaded directly in your go path

muralisr
2016-08-29 15:17
and if it did, chaincode will fail to download (as the code is already in gopath)

shichaoyuan
2016-08-30 03:21
has joined #fabric-dev


jonathanlevi
2016-08-30 08:35
----- Reminder: @jonathanlevi is on holiday until next Tuesday, and has extremely limited internet access. -----

ghaskins
2016-08-30 12:09
@jcarrivick suggest abandoning https://gerrit.hyperledger.org/r/#/c/725 for now since we reverted the protoc patch….we can regroup in a branch that includes the original patches together.

ghaskins
2016-08-30 15:13

yacovm
2016-08-30 15:21
I don't understand something, you claimed there was a problem in which vendor files are compiled from some reason, yet you upload a patch that dynamically compiles the proto files and leave out the proto version upgrade, but... I'm pretty sure that the proto upgrade itself isn't what was causing the vendor file compilation, but rather the dynamic compilation was. Does what I just said make sense or maybe I have some wrong assumption?

ghaskins
2016-08-30 15:27
I didnt claim that the protoc upgrade was the cause, but its prudent to isolate the two changes out

ghaskins
2016-08-30 15:27
its something we should have done from the beginning, but se la vie

ghaskins
2016-08-30 15:28
i figured it makes more sense to do the dynamic compile first, so we dont waste a cycle committing the v3.0.0 pb.go files, so I did this one first

ghaskins
2016-08-30 15:28
once that is proven stable, ill take the second half of your patch and submit it as a discrete patch

yacovm
2016-08-30 15:29
hmm, I actually think it's the opposite- if you do the upgrade, and leave the pb.go files it'll surely won't have a problem of vendor compilation, since no proto files are being compiled

yacovm
2016-08-30 15:29
Of course, not that I'm one to decide or anything, just saying my opinion

ghaskins
2016-08-30 15:30
i agree that doing the upgrade isnt likely to impact errant makefile rules…all I am saying is that doing the upgrade first means we have to regenerate commited .pb.go files only to turn around and delete them in a follow up patch

ghaskins
2016-08-30 15:30
it seemed suboptimal

ghaskins
2016-08-30 15:30
i dont think its a huge deal either way

yacovm
2016-08-30 15:30
why? in the follow-up patch we only impact the Makefile et. al won't we?

ghaskins
2016-08-30 15:31
well, we delete any commited pb.go files in the dynamic support, right?

yacovm
2016-08-30 15:31
I see

yacovm
2016-08-30 15:31
yep

ghaskins
2016-08-30 15:32
its also unclear what, if any, side effects we may be seeing as a result of the upgrade

ghaskins
2016-08-30 15:32
so, doing two discrete patches makes sense to me, and doing the dynamic one first seemed to generate less git chatter

yacovm
2016-08-30 15:32
when I did the patch, I first upgraded the proto version and all the pb.go files, ran the tests, and only after that- messed with the dynamic compilation. So, it should work...

yacovm
2016-08-30 15:32
but yeah I understand now

ghaskins
2016-08-30 15:32
you are probably right, but I had to pick one vs the other

yacovm
2016-08-30 15:36
As long as one can take later the updated files that changed(from my patch), and merge it without conflicts to the master that'll be at that point, we still benefit from my patch.

gennady.laventman
2016-08-30 15:42
@hgabor , @muralisr : I updated https://gerrit.hyperledger.org/r/#/c/535/ according to your comments and replayed to your comments as well. Can you look into it again?

chainsaw
2016-08-30 15:59
has joined #fabric-dev

jachtermann
2016-08-30 16:26
has joined #fabric-dev

ccorley
2016-08-30 16:36
has joined #fabric-dev

hgabor
2016-08-30 17:10
@gennady.laventman: I will check it

gennady.laventman
2016-08-30 17:11
@hgabor : I will push merged version soon

gennady.laventman
2016-08-30 17:37
@hgabor : Pushed rebased patch

ghaskins
2016-08-30 22:34

jeffgarratt
2016-08-30 23:41
@ghaskins has there been any thought to bumping up the docker-compose version?

ghaskins
2016-08-30 23:42
no one has mentioned it, but sounds reasonable to me

yacovm
2016-08-31 06:57
@ghaskins , the signed off by contains my name so I guess it's based on my patch? I so- what did you change in comparison to my patch, in a few words?

bgorman
2016-08-31 08:16
is this a random failure of fabric/core/crypto/crypto_test.go? I feel it's unlikely I've broken it with my changes https://jenkins.hyperledger.org/view/fabric/job/fabric-verify-x86_64/745/console

bgorman
2016-08-31 08:31
now my reverify failed because vagrant provision couldn't install "default-jre" https://jenkins.hyperledger.org/job/fabric-verify-x86_64/747/console

bgorman
2016-08-31 08:32
08:17:04 The following packages have unmet dependencies: 08:17:04 default-jre : Depends: default-jre-headless (= 2:1.7-51) but it is not going to be installed 08:17:04 Depends: openjdk-7-jre (>= 7~u3-2.1.1) but it is not going to be installed

hgabor
2016-08-31 08:50
shall I merge this? https://gerrit.hyperledger.org/r/#/c/729/ verify always fails with different random issues...

simon
2016-08-31 09:25
maybe we should trace what random issues fail

simon
2016-08-31 09:26
and then fix those first, before adding features

hgabor
2016-08-31 09:58
lets try it locally

ghaskins
2016-08-31 11:51
@yacovm: no changes, I literally did a "git cherry-pick" of your original work. Git dropped the parts that I already did (like delete the pb.go files) and I had to conflict resolve the Makefile. That's it. I left your DCO out of respect/credit to you since it was your work, but I can drop if you are not comfortable

ghaskins
2016-08-31 11:53
(Btw, leaving DCO trail during merge resolution is standard for most projects)

simon
2016-08-31 12:18
ok

yacovm
2016-08-31 12:18
no I was just wondering

ghaskins
2016-08-31 12:23
ok

hgabor
2016-08-31 12:40
I have the same problem as @bgorman

simon
2016-08-31 13:55
@muralisr: again, to make sure, a chaincode's Init function is invoked every time the container is started?

muralisr
2016-08-31 13:57
@simon … no. but let us make sure we are talking about the same thing. deploy, chaincode dies, invoke, chaincode container is brought up again…. init won’t be called

simon
2016-08-31 13:57
when is Init() called?

muralisr
2016-08-31 13:58
when you deploy

simon
2016-08-31 13:58
aha

gennady.laventman
2016-08-31 14:02
I have same problem with build

cbf
2016-08-31 14:24
think we are picking up a flakey ubuntu image

cbf
2016-08-31 14:24
keep reverifying

hgabor
2016-08-31 15:56
for one of my commits, it seems to be fixed now, the ubuntu things @cbf

garisingh
2016-08-31 17:47
did http://gerrit.hyperledger.org disappear? or do I just have a flaky internet connection?

ghaskins
2016-08-31 17:50
discussed on #ci-pipeline, LF DNS problems

garisingh
2016-08-31 17:52
hmm - we give LF an awful lot of money for them to not properly manage DNS

garisingh
2016-08-31 17:52
:wink:

garisingh
2016-08-31 17:52
I expect a globally resilient network - haha

cbf
2016-09-01 00:13
ok, I am going to create a v0.6 branch without developer-preview suffix as discussed, will create from master


david.acton
2016-09-01 11:07
Hi, Sorry if this has already been mentioned, but when I try and use the latest docker hyperledger/fabric-membersrvc It just seems to hang. I have to go back a few revisions to find one that works. Is there an issue or a API change?

david.acton
2016-09-01 11:09
@garisingh You know who has a globally resilient network and is FREE for open source……. GitHub.. We should consider that :wink:

ghaskins
2016-09-01 11:51
@david.acton: I think that is FAD for the latest code. You can explicitly enable logging to see old behavior

ghaskins
2016-09-01 11:51
It's not really hung, just quiet

hgabor
2016-09-01 12:03

david.acton
2016-09-01 12:04
@ghaskins Hi, Thanks for the response! That makes sense, but when I try to connect to port 50051 using GRPC I get There was an error: rpc error: code = 14 desc = grpc: the connection is unavailable …. Where if I use a previous image, all is good

david.acton
2016-09-01 12:04
Has the port changed?

ghaskins
2016-09-01 12:05
yeah, a few weeks ago…its something in the 7050 range now, let me look


david.acton
2016-09-01 12:05
cool! How do I keep up on such changes?

ghaskins
2016-09-01 12:05
ML/slack is best bet

ghaskins
2016-09-01 12:06
that type of disruption is (hopefully) rare though

david.acton
2016-09-01 12:06
@ghaskins as usual you’re an absolute star!! Thanks for the help!

ghaskins
2016-09-01 12:06
any time

simon
2016-09-01 12:08
hgabor: again?

simon
2016-09-01 12:08
this viper needs to go away

simon
2016-09-01 12:08
and all the tests need to be changed

simon
2016-09-01 12:08
beuh

hgabor
2016-09-01 12:10
is he one?

cbf
2016-09-01 12:36
@simon: suggestions?

simon
2016-09-01 12:37
i think we should ditch viper

simon
2016-09-01 12:37
i listed various other options in an issue a long time ago

cbf
2016-09-01 12:37
agree, it is suboptimal

simon
2016-09-01 12:37
nobody cared tho

simon
2016-09-01 12:38
it is slow (and people are caching results), and it tolerates incorrectly spelled settings

simon
2016-09-01 12:38
which is a disaster

hgabor
2016-09-01 12:48
https://jenkins.hyperledger.org/job/fabric-verify-x86_64/797/console first 'unstable' Jenkins verify I ve ever seen in this Jenkins

hgabor
2016-09-01 13:01
any ideas what happened? it seems that the problem was with the reports

cbf
2016-09-01 13:03
I've seen that a couple times

cbf
2016-09-01 13:03
will have @ramesh look into it

ramesh
2016-09-01 13:04
@hgabor I see some XML parsing error in behave test results report


hgabor
2016-09-01 13:05
btw I keep writing reverify all the day for a lot of commits. e.g. for yours, ramesh :slightly_smiling_face:

hgabor
2016-09-01 13:05
very unstable

hgabor
2016-09-01 13:18
and now the well-known jdk-jre problem

david.acton
2016-09-01 17:50
Hey gang. Is there any chance we can be more specific on the error “sql: no rows in result set”?

cbf
2016-09-01 18:04
@david.acton https://jira.hyperledger.org/browse/FAB-298 though there is a refactor of the ledger beginning and this may be moot sooner than we think… I will see if it is a simple fix

cbf
2016-09-01 18:12
@david.acton could you please update that issue with any info that might help reproduce? Would be extremely helpful.

binhn
2016-09-01 18:53
@cbf @ry Pat just submitted the SDK code to handle events https://gerrit.hyperledger.org/r/#/c/851/ — we really need that; could we add that to 0.6

cbf
2016-09-01 18:53
need to submit also to that branch

cbf
2016-09-01 18:54
git push origin HEAD:refs/for/v0.6

binhn
2016-09-01 18:55
ok

cbf
2016-09-01 18:55
that should create another changeset for the branch

binhn
2016-09-01 18:59
@cbf he got an error pmullaney [2:56 PM] sure [2:57] failed new messages [2:57] To ! [remote rejected] HEAD -> refs/for/v0.6 (no new changes)

binhn
2016-09-01 19:00
@pmullaney

ghaskins
2016-09-01 19:01
My guess is it needs a new ChangeID

cbf
2016-09-01 19:02
yes

cbf
2016-09-01 19:03
I think that you may want to make that from a branch that is initialized from HEAD of the v0.6 branch too

cbf
2016-09-01 19:03
pushing my non-existent Gerrit skills

cbf
2016-09-01 19:03
maybe @bramwelt can help?

ghaskins
2016-09-01 19:15
@cbf we should probably change the version tag in master now

ghaskins
2016-09-01 19:16
ill push that when I push the mirror-revert to 0.6

binhn
2016-09-01 19:32
@pmullaney i don’t know the magic cmds either, so with my limited knowledge, i think you should do the following: <save your changed files> git checkout v0.6 git fetch origin v0.6 git pull origin v0.6 <copy your changes over and commit change set> git push origin HEAD:refs/for/v0.6

pmullaney
2016-09-01 19:42
I did the following:

pmullaney
2016-09-01 19:42
git pull origin v0.6

pmullaney
2016-09-01 19:42
git checkout v0.6

pmullaney
2016-09-01 19:42
git cherry-pick bc36816ba06b4f9e1354e77b8602ce4b540cd81c

pmullaney
2016-09-01 19:43
which was the commit from my sdk-events branch

pmullaney
2016-09-01 19:43
git push

ghaskins
2016-09-01 19:43
@pmullaney did your commit log have a ChangeID in it already?

pmullaney
2016-09-01 19:43
fails because of access rights

pmullaney
2016-09-01 19:44
yea it did

ghaskins
2016-09-01 19:44
ok, i see two potential problems

ghaskins
2016-09-01 19:44
1) dont “git push” without qualifying the origin/branch (e.g. git push gerrit HEAD:refs/for/v0.6)

ghaskins
2016-09-01 19:45
2) try editing the commit log to remove the change id and have another generated

ghaskins
2016-09-01 19:45
its just a guess, but I am wondering if gerrit only intends changeid to be used in one flow

ghaskins
2016-09-01 19:46
i think the perms-denied is because IIUC you tried to do an unqualified push which will default directly to the branch instead of “refs/for"

ghaskins
2016-09-01 19:46
and I think the no-op is because it thinks its the same as the changeid already there

pmullaney
2016-09-01 19:47
gerrit being my local v0.6 branch with the cherry picked commit?

ghaskins
2016-09-01 19:47
sorry, “gerrit” is a remote in my setup

ghaskins
2016-09-01 19:47
not sure which remote you have

ghaskins
2016-09-01 19:47
probably “origin” for you

ghaskins
2016-09-01 19:48
the general form is “git push $remote HEAD:refs/for/$branch"

pmullaney
2016-09-01 19:48
ok I *think* that went thru

ghaskins
2016-09-01 19:48
where $remote/$branch are context specific

ghaskins
2016-09-01 19:48
yep, looks right


pmullaney
2016-09-01 19:49
great thanks

roman.pavlov
2016-09-01 19:58
has joined #fabric-dev

roman.pavlov
2016-09-01 19:58
Are non validating peers going to be deprecated in the near future, along with the rest api?

cbf
2016-09-01 20:10
@ghaskins lost some context

cbf
2016-09-01 20:10
what are we mirroring? v0.6?

cbf
2016-09-01 20:20
@ghaskins so what is the flow?

cbf
2016-09-01 20:21
1. git pull origin v0.6 2, git checkout v0.6 3. git cherry-pick bc36816ba06b4f9e1354e77b8602ce4b540cd81c

cbf
2016-09-01 20:21
4. git commit —amend and remove the change-id?

cbf
2016-09-01 20:22
then git push gerrit HEAD:refs/for/v0.6 ?

ghaskins
2016-09-01 20:27
@cbf I think so

cbf
2016-09-01 20:27
trying now

ghaskins
2016-09-01 20:27
keep in mind, i am no expert, that just seems to be whats needed to make gerrit happy

cbf
2016-09-01 20:27
for 831

cbf
2016-09-01 20:27
we are all children with gerrit

ghaskins
2016-09-01 20:27
heh


kostas
2016-09-01 20:32
Before we can even consider an external package for vendoring, what are the acceptable licenses for our project?

cbf
2016-09-01 20:32
apache

kostas
2016-09-01 20:34
But Viper, for instance, is MIT-licensed.

binhn
2016-09-01 20:55
@roman.pavlov yes, it is very much replaced by committer, and the rest api is depreciated in preference of grpc with SDK

binhn
2016-09-01 20:57
@cbf did the steps work? probably we should pin it somewhere so others can follow

cbf
2016-09-01 21:18
I will post email and update docs

cbf
2016-09-01 21:18
those are correct steps

yaoguo
2016-09-02 03:10
How can I get deploy or invoke result directly? It seems that success response only means deploy or invoke tx was sended to consenter.

bgorman
2016-09-02 03:34
@yaoguo what API are you using to deploy and invoke?

yaoguo
2016-09-02 03:36
CLI now. Is REST different?

yaoguo
2016-09-02 03:36
@bgorman

bgorman
2016-09-02 03:36
REST does the same thing. You could try the node sdk

bgorman
2016-09-02 03:36
I'm not sure if it is better

bgorman
2016-09-02 03:37
I usually just check the blockchain for the result

bgorman
2016-09-02 05:37
did the logging get changed in membersrvc/ca? a lot of the example chaincode used to call `ca.LogInit(ioutil.Discard, os.Stdout, os.Stdout, os.Stderr, os.Stdout)` but it is undefined now

bgorman
2016-09-02 05:42
from this commit it looks like I should just remove any of those LogInit functions.... https://gerrit.hyperledger.org/r/gitweb?p=fabric.git;a=commit;h=0ea65fd1ddbcffb83eef851cd63e25fdd2574855

bgorman
2016-09-02 06:59
Is Jenkins completely broken at the moment? 06:27:21 make: *** No rule to make target `unit-tests'. Stop.

bgorman
2016-09-02 07:01

bgorman
2016-09-02 07:25
oops ... it looks like I need to merge in some Makefile changes

cbf
2016-09-02 10:45
broken... I think @ramesh has a patch to be merged

hgabor
2016-09-02 10:49
which branch do you mean?

hgabor
2016-09-02 10:49
isn't that patch already merged on master?

hgabor
2016-09-02 10:50

hgabor
2016-09-02 11:11
@cbf

garisingh
2016-09-03 13:48
so not sure what's exactly what's going on here, but looks like CI is broken due to some confusion between branches

garisingh
2016-09-03 13:49
I have an update to date copy of master on my local machine and can reproduce the same error - looks like somehow master is using an image which has chaincode resources from the convergence branch

gennady.laventman
2016-09-04 11:46
Hi. Is anybody here?

gennady.laventman
2016-09-04 11:49
Any news about build?

garisingh
2016-09-04 11:51
I am here

garisingh
2016-09-04 11:52
no one seems to be responding to me about how to best solve the problem. I know the issue but given I have no control / access to make changes in any repo makes it tough to fix. I am going to fix it using my own repo and then we can put that structure in place in the main repo later

garisingh
2016-09-04 11:52
are you pushing to the master branch?

gennady.laventman
2016-09-04 12:16
Right now yes.

garisingh
2016-09-04 12:32
I am currently running the entire build process on my local machine with my proposed fix

garisingh
2016-09-04 12:33
this is going to continue to be problematic with multiple branches and all these changes being made to the chaincode interface because Go versioning sucks. There are things we can do, but we need to start putting that stuff in place

gennady.laventman
2016-09-04 12:44
Agreed.

garisingh
2016-09-04 12:52
and people really need to start making sure they enter things in JIRA and use JIRA to discuss breaking changes, etc. Else no one will have any idea what is actually going on

garisingh
2016-09-04 12:52
it is actually quite frustrating

lbonniot
2016-09-04 13:00
Hi @garisingh ; could you please explain why "go versioning sucks" in this case? I'm quite interested :wink:

garisingh
2016-09-04 14:11

garisingh
2016-09-04 14:13
the problem really stems from trying to do "go get" for something that is not currently in your GOPATH. "go get" supports github URLs, but it will only pull from the HEAD of the master branch

garisingh
2016-09-04 14:17
so let's see you have something which requires packageA which you import as "http://github.com/packageA" and you don't keep it in your local GOPATH src tree. So today you do a go build / go install on your package which used packageA. Now let's say that night somebody decides to change the public interface methods for packageA. The next day you clean your project and/or share it with someone else. They clone your project and now when they try to build it it won't compile because the version of packageA they get have the new interface methods

garisingh
2016-09-04 14:25
@cbf @ghaskins - https://gerrit.hyperledger.org/r/#/c/901/ - my attempt to temporarily fix the broken build for master

garisingh
2016-09-04 14:27
continuing from above - the problem for us right now is that we multiple branches which use different versions of chaincode interfaces and we were trying to use a common remote resource

lbonniot
2016-09-04 14:28
Ok, thanks for the explanation :slightly_smiling_face: IMHO, Vendoring is addressing this issue, but in this case the main problem is that this test is downloading remote artifacts... If the purpose is to test the downloading thing, would it be doable to Mock something instead of downloading blindly from Github?

garisingh
2016-09-04 14:29
the fabric currently supports deploying chaincode from a remote repo (this is what the REST interface does). We can probably eventually get rid of this once we remove the REST API, but the problem will continue in other places as well

garisingh
2016-09-04 14:30
but we can vendor, but we would need to actually start enforcing / explaining that as a mandatory practice for developing chaincode. On the other hand, we really should start versioning certain things anyway

chainsaw
2016-09-04 16:55
@garisingh I would suggest the project instills versioning in the code and not rely on build tools to sort out what is a bullet train of continuous code modifications from out-of-sync parties. Look at Bitcoin core for an example of creating robust code that is smart enough about allowing multiple versions of code to co-locate and operate independently.

garisingh
2016-09-04 17:03
@chainsaw - you won't get any arguments out of me. I have actually mentioned this in other posts - specifically when it comes to the interface(s) which chaincode authors are required to implement

garisingh
2016-09-04 17:04
Given I have actually been running the fabric as a service for most of the year and running multiple versions of the fabric code (which BTW needs to start cutting actual releases), I have been suffering though this issue for a long time

garisingh
2016-09-04 17:05
BUT - Go is definitely not as "version" friendly when it comes to packaging as are other languages

chainsaw
2016-09-04 17:07
@cbf can you point me to a resource that documents the official Hyperledger Fabric development workflow and procedure, so I can understand how code is created, reviewed, committed, and assigned developers working on specific components, etc.? Is there a repo that contains code that has passed all builds and tests and does not break (stable)? Also, is there any resources that target non-hyperledger members (public) developers, like where to pull / clone code from, how to deploy the nodes without the devenv VM. For example say someone wants to deploy and run the behave tests on AWS or Azure. Is there a roadmap document that developers can read so they do not get boxed in to code and design that is going to be swapped out, removed, or refactored. This will prevent a lot of frustration for those investing in work only to see their dependencies removed.

chainsaw
2016-09-04 17:10
@garisingh I feel your pain :slightly_smiling_face:

chainsaw
2016-09-04 17:14
@garisingh personally I think and I will subject the code (source and bin) to the blockchain and integrate a chaincode repo that prevents this issue. This could manifest down the road and present a fragile and risky runtime environment by opening a vector for abuse :disappointed: Best to address now why the design and code are still in the infant stage.

cbf
2016-09-04 18:52
@chainsaw http://hyperledger-fabric.readthedocs.io/en/latest/#fabric-developer-guide - but there’s more to it than just that

cbf
2016-09-04 18:54
basically, we use JIra for issue and story tracking. If you see something you’d like to work on, LMK and either @garisingh or I can get you integrated

cbf
2016-09-04 18:55

chainsaw
2016-09-04 19:49
Awesome! Thx @cbf. But I'm not a member, so I can't work on (contribute) code :disappointed:

chainsaw
2016-09-04 20:36
@cbf Hey I got my LF ID so I guess I'm good to GO :slightly_smiling_face: pun untended.

cbf
2016-09-04 20:36
;-_

cbf
2016-09-04 20:36
sweet

cbf
2016-09-04 20:36
ping me with any questions… @ghaskins and @garisingh are also good resources

chainsaw
2016-09-04 20:37
thx 4 prompting me into hyperlight @cbf!

muralisr
2016-09-04 20:57

garisingh
2016-09-04 22:08
@muralisr - thanks

garisingh
2016-09-04 22:09
I also pushed a patch for review - temporary most likely - but will allow CI to work for master

jcarrivick
2016-09-05 03:50
Does anyone know how often the Github mirrors are updated?

cbf
2016-09-05 08:08
every merged patch I believe

cbf
2016-09-05 08:08
@ry set it up

jcarrivick
2016-09-05 08:13
thanks @cbf, it just seems to be a few days behind

jcarrivick
2016-09-05 08:13
Not that it bothers me, was just curious

cbf
2016-09-05 08:41
could be a glitch - will have it looked at

hgabor
2016-09-05 09:10
@cbf https://gerrit.hyperledger.org/r/#/c/841/ how exactly did you mean?

cbf
2016-09-05 10:34
it seems like every day you are proposing yet another change

hgabor
2016-09-05 10:47
this is not related to my other changes (which were only submitted to the feature branch...). this was requested by users

hgabor
2016-09-05 10:48
and I don't think it is big change to have a getter for a field

rvaughan
2016-09-05 10:53
has joined #fabric-dev

garisingh
2016-09-05 10:53
IMHO, every change must be tied to a JIRA entry. We need to be able to understand why changes are being made, who is requesting them and where they fit into the (eventual) release milestones

hgabor
2016-09-05 10:55
I thought @novusopt will open a JIRA for it, but I can do it if there isn't one

hgabor
2016-09-05 11:07

garisingh
2016-09-05 11:25
although as @cbf mentioned, there is definitely a lot of churn going on with the chaincode interfaces. this is not a problem if you are someone who is keeping up with the bleeding edge of fabric, but the lack of releases causes a lot of issues when trying to simply build, compile and test chaincode

hgabor
2016-09-05 11:36
the chaincode API on master hasn't changed yet, so I don't exactly understand your opinion

garisingh
2016-09-05 11:36
ah - that's true - not on master - although it has changed significantly on master since we cut the v0.5-developer-preview release

hgabor
2016-09-05 11:37
if you mean the base64 thing (as I remember that was the only change), that is unrelated to this, and it is kinda 'reverted' in a sense that one can use the 'old, usual' REST API and cli calls

garisingh
2016-09-05 11:37
but my point is valid - even this one change is going to break people who store their chaincode in github and attempt to build it

garisingh
2016-09-05 11:38
well maybe not this change :wink:

hgabor
2016-09-05 11:39
it would only break that kind of code (not only this but any chaincode related change) if it changed the API (Invoke, Init, Query). or not?

garisingh
2016-09-05 11:44
I think we are generally safe as long as we don't break the interfaces chaincode is required to implement / use

garisingh
2016-09-05 11:45
so adding a function should be ok. changing one would break the chaincode if they compile / deploy it against an up level of the peer

hgabor
2016-09-05 11:52
this is generally the same as what I said :slightly_smiling_face: - or not?

garisingh
2016-09-05 11:53
yeah

garisingh
2016-09-05 11:54
but it would be both the Chaincode and ChaincodeStubInterface

hgabor
2016-09-05 11:56
we can also reject the change and I can upload it to feature/convergence

garisingh
2016-09-05 11:58
well now is the time to get in any changes we think would be worthwhile to merge down to the v0.6 release

garisingh
2016-09-05 11:59
although it is still unclear to me how / when we are cutting that release

garisingh
2016-09-05 11:59
and this one does seem useful

chainsaw
2016-09-05 22:25
@cbf is it inferred that a "merged patch" does not break the build, since github is updated post-merge? So, one can at anytime clone github hyperledger-fabric and build without error?

garisingh
2016-09-05 22:31
@chainsaw - that's the goal and generally holds true

cbf
2016-09-05 22:38
occasionally there can be breakage

chainsaw
2016-09-05 22:41
I have always maintained a master that ALWAYS builds. You don't add code unless it passes all tests performed by CI jobs responsible for committing code to the master. Everything else is in flux, but NO code gets in master if it breaks CI. There needs to be stages that code must move through, beginning with review. Then it is pushed to an integration CI build and if it passes then it is moved to a hot master tmp clone and if it builds with master then it is committed to the true master. Each primary branch should follow this pattern. And commits between branches also follow the "no-breaks" allowed rule. There is nothing more frustrating (and unproductive) to a developer than code that worked this morning but is broke this afternoon, because a peer added code that works in his env, but not in the system smoke out env :slightly_smiling_face: I'm new so maybe this is happening but has some issues yet to be shaken out :slightly_smiling_face: I just know that figuring out what and where to get the code that you can build without errors consistently is currently stressful, because you just cross your fingers and hope.

chainsaw
2016-09-05 22:54
Can I be pointed to a document that explains the branches--their purpose, and relationship to the other branches? And another document that explains the CI design, jobs, procedures, etc. so I can understand the flow from developer to release? Is there a planned release cycle or target? How can I get tuned into the process being used to negotiate the features that are being decided on and scheduled for development?

jcarrivick
2016-09-06 01:28
Hi folks, just wondering if anyone might be aware if there were any particular reasons why the `CORE_VM_ENDPOINT` in the BDD Tests was chosen to be the Docker IP as opposed to the Socket at `/var/run/docker.sock`. Just looking at changing it so that Jenkins doesn't need to do any nasty `sed` substitution in the docker-compose config files for running the tests

hanhzf
2016-09-06 05:12
has joined #fabric-dev

simon
2016-09-06 08:56
jcarrivick: you need to map this socket into the peer container, so that the peer in the container can talk to the docker service

pushpalatha
2016-09-06 09:32
AnyOne know where the logs go when we log something in our code using op/logging ? In earlier versions we used to see that on register chain code console...

bryan-huang
2016-09-06 10:47
has joined #fabric-dev

simon
2016-09-06 11:02
pushpalatha: docker container stdout

pushpalatha
2016-09-06 11:04
@simon : No.. i am unable to see the logs there...

garisingh
2016-09-06 11:10
@jcarrivick - As you know, in the BDD tests the peers run in Docker as well. If you want to use `/var/run/docker.sock` it adds a few complexities: 1) You'll need to mount `/var/run/docker.sock` as a volume 2) You'll need to either run the peer container(s) in privileged mode (you might also be able to simply add the user the process is running as to the `docker` group as well)

garisingh
2016-09-06 11:10
Why can't we just use the same TCP port for the Docker daemon?

garisingh
2016-09-06 11:11
what substitution are we making now? (I could look but :wink: )

pushpalatha
2016-09-06 11:29
@simon : the console where docker-compose up runs, i am double sure that it is not logging.. That is why i'm lost. Please confirm



hgabor
2016-09-06 13:11
can somebody review those?

jonathanlevi
2016-09-06 17:01
@hgabor: `913` has a pending a question from Gari, and `785` is merged, but the post-merge build FAILs.

jonathanlevi
2016-09-06 17:01
I hope you missed me :wink:

hgabor
2016-09-06 17:02
oh really I did

hgabor
2016-09-06 17:03
the post-merge thing seems to be some instability

hgabor
2016-09-06 17:04
do you mean this from @garisingh : LGTM

chainsaw
2016-09-06 18:52
@ghaskins Where can I find release v0.5? I need the release deployed on BMX to demo IBM learn-chaincode tomorrow without modifying it for the new chaincode interface, because I will deploy to BMX and execute it there.

garisingh
2016-09-06 19:36
@chainsaw - http://github.com/hyperledger-archives/fabric and then you'll see the v0.5-developer-preview branch

chainsaw
2016-09-06 20:10
sweet! thx @garisingh

ramesh
2016-09-06 22:36
Someone please look into to this issue https://jira.hyperledger.org/browse/FAB-101

ramesh
2016-09-06 22:36
seeing this error in the recent builds ```5:17 --- FAIL: TestClassicBackToBackStateTransfer (60.13s) 16:35:17 2016/09/06 16:35:16 Halting timer 16:35:17 panic: Test network took more than 60 seconds to resolve requests, this usually indicates a hang [recovered] 16:35:17 panic: Test network took more than 60 seconds to resolve requests, this usually indicates a hang```

jcarrivick
2016-09-07 00:07
@garisingh I got it all working here: https://gerrit.hyperledger.org/r/#/c/909/ I did have to add the volume like you suggested with the exception that the version of docker-compose we run doesn't support mounting single files as a volume so I had to mount the entire `/var/run/` folder from the host. Not ideal, but we would have to upgrade both docker and docker-compose in Jenkins (which we probably should do at some point) in order to only mount `/var/run/docker.sock` sed currently replaces the IP in `bddtests/compose-defaults.yml` with the host's docker IP, changing it to the socket would decouple the tests further from the environment they are running in.

chainsaw
2016-09-07 01:27
@garisingh how do "delete" a deployed chaincode? If I want to update it do I just deploy the updated version again? I realized the chaincode ID is unique and generated for each deploy. So how would "re"deploy?

chainsaw
2016-09-07 01:28
@garisingh on BMX that is.

mrshah
2016-09-07 01:35
@chainsaw are you using SDK to deploy the chaincode?

chainsaw
2016-09-07 01:39
So I took the v0.5 release from the archive and created a public github repo then changed all occurrences of "hyperledger/fabric" in the code to TarantulaTechnology/fabric (my new repo) then updated the IBM learn-chaincode code in my learn-chaincode repo to the new path and was able to compile without the shim errors. I was able to deploy it to BMX :slightly_smiling_face: Now I have a working v0.5 to use with the IBM code that only works with v0.5 which is the deployed version on BMX. This allows me to share with new engineers how to build chaincode and let's them deploy it without the headache of mastering the devenv and the stream of continuous changes :slightly_smiling_face: This allows them to focus on one thing the chaincode, before deciding if they want to jump into the deep water of devenv :slightly_smiling_face:

chainsaw
2016-09-07 01:42
@mrshah I'm using Swagger UI on Bluemix IBM Blockchain service. This is for teaching chaincode development--entry level. I do use it in my experimental development though. I will utilize it and front-end it.

mrshah
2016-09-07 01:43
so, if you update the chaincode, it should generate a new chaincode ID

mrshah
2016-09-07 01:43
are you saying you want to replace the existing chaincode with a new one keeping the same data underneath?

chainsaw
2016-09-07 01:48
Right, I deployed a chaincode, added a new method to it, and now want to redeploy it. My curiosity wonders if the prior chaincode is still out there and can be accessed. I want to effectively destroy it and deploy my new version or I might want to keep it and run to versions one without the new method and one with it. Flexibility is required.

chainsaw
2016-09-07 01:49
I

chainsaw
2016-09-07 01:49
I'll just experiment for now and see what happens. Thx @mrshah

mrshah
2016-09-07 01:50
I don't think you can destroy chaincode using the REST APIs

mrshah
2016-09-07 01:50
you can deploy a new one and switch to using it

chainsaw
2016-09-07 02:22
The Bluemix IBM Blockchain service is limited in this regard. It too is beta but is great for playing and utilizes Swagger to allow easy interaction with the various components. It's v0.5 so I had to go back in time to make my demo work. My focus is in the SDK too I just haven't had the time to drill down on it and my gut is telling me I should wait because a lot of work is taking place and trying to grasp a bullet is dangerous so I sit play watch experiment until my gut says the cement and iron is in place and the foundation will no longer be shifting under my feet. Plus I expect to do a ton of customization to Hyperledger too.

hgabor
2016-09-07 14:36
btw: https://gerrit.hyperledger.org/r/#/c/943/ same HTTP test error as yesterday. wasn't that fixed? rebase helped for other commits.

garisingh
2016-09-07 15:06
yeah - that's odd. did you rebase?

hgabor
2016-09-07 19:59
last time (3 hours ago) I tried it said it is up to date @garisingh

bala.vellanki
2016-09-07 21:58
has joined #fabric-dev

xiejunan
2016-09-08 01:58
has joined #fabric-dev

mtakemiya
2016-09-08 02:17
What is the reasoning for not having an undeploy for chaincode?

ghaskins
2016-09-08 02:26
@mtakemiya its purely a function of project maturity. There are plans for full chaincode lifecycle management including deployment, update, and termination

ghaskins
2016-09-08 02:26
just right now, only deploy is available

mtakemiya
2016-09-08 02:27
Okay. Is there any documentation on the final vision for chaincode?

muralisr
2016-09-08 02:48
@mtakemiya documentation is work in progress.. will be first brought to the community. But for a starter sketch take a look at https://jira.hyperledger.org/browse/FAB-183 (also FAB-182)

muralisr
2016-09-08 02:52
just talks about upgrade and deploy but introduce “lifecycle”

ghaskins
2016-09-08 02:52
thank you @muralisr, was struggling to find the pointer

muralisr
2016-09-08 02:52
thank you too!

ghaskins
2016-09-08 02:52
@cbf ping

muralisr
2016-09-08 02:53
need to air these things more

ghaskins
2016-09-08 02:53
yeah, hopefully we converge on a wiki solution soon

muralisr
2016-09-08 02:53
that will help for sure

mtakemiya
2016-09-08 10:11
Thanks ^ ^

pushpalatha
2016-09-08 10:38
Hi All, Any idea why we get this : membersrvc_1 | 2016/09/08 10:37:42 grpc: Server.Serve failed to complete security handshake. vp0_1 | 2016/09/08 10:37:43 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: write tcp 172.17.0.3:44224->172.17.0.2:7054: write: broken pipe"; Reconnecting to "membersrvc:7054"

kostas
2016-09-09 04:06
@kostas uploaded a file: https://hyperledgerproject.slack.com/files/kostas/F29S2N4JE/_make_all__output.sh and commented: What's going on here?

ry
2016-09-09 04:09
weird. we don’t have any images with a name like that: https://hub.docker.com/u/hyperledger/ shows what we have

jcarrivick
2016-09-09 04:11
@kostas try a `make images-clean` and then try again

ry
2016-09-09 04:13
@kostas looking at this console log, we build that. I think @jcarrivick is correct. https://jenkins.hyperledger.org/job/fabric-merge-x86_64/157/console


jcarrivick
2016-09-09 04:15
it's because the version was bumped from 0.6 to 0.7 recently and it won't be able to find the 0.7 images because they're still tagged as 0.6

kostas
2016-09-09 04:25
Thank you, will give `make images-clean` a go.


kostas
2016-09-09 04:28
That didn't go as expected.

ashishkel
2016-09-09 05:14
has joined #fabric-dev

ashishkel
2016-09-09 05:19
Hi, Just trying to confirm, whether the hash/"chaincode id" is supposed to change the second time deploy, if i deploy a chaincodeA with say initialization parameters a=100,b=200 first AND deploy again with a=300,b=400 ?

jcarrivick
2016-09-09 05:22
@kostas that's fine, just try `make unit-test` again and it'll rebuild the images

bgorman
2016-09-09 06:38
@ashishkel I believe the hash has nothing to do with the deploy args... it is a hash of all the files in the chaincode directory, make sure you don't have any extra files in there with `ls -lah`

xiejunan
2016-09-09 09:04
'make protos' will report:

xiejunan
2016-09-09 09:09
protoc-gen-go: error: inconsistent package names: extension_extra extension_base . What's the wrong with my enviroment? please help me.

deeflorian
2016-09-09 09:47
@ashishkel @bgorman arguments are also a parts of the hashing, so changing args changes CCIDs (at least it used to on the main branch version a few days back)

hgabor
2016-09-09 09:54
@deeflorian changing args change chaincode ID? as @bgorman said chaincode ID is a hash of all the files in the chaincode directory

hgabor
2016-09-09 09:54
changing args change TxID

deeflorian
2016-09-09 10:22
it definitely used to change it -- will check in a moment (@csehd)

hgabor
2016-09-09 10:24
where did it change that? chaincode ID is e.g. needed for deployment, do you mean that different deploy args lead to different CCIDs?

a.klenik
2016-09-09 10:41
has joined #fabric-dev

ashishkel
2016-09-09 12:12
@hgabor : that was my question. Whether deployment with differnt args lead to differnt CCIDs..

ashishkel
2016-09-09 12:15
Anyways, as @bgorman mentioned, i will check with the ls -ltra also and come back to you folks


ashishkel
2016-09-09 12:17
Protocol spec defines as > chaincodeID - The ID of a chaincode which is a hash of the chaincode source, path to the source code, constructor function, and *parameters*.

hgabor
2016-09-09 12:20
@ashishkel wow that's weird, last time I had an error with a chaincode ID somebody said that it only depends on the source code

hgabor
2016-09-09 12:21
@ashishkel I mean some expert of the topic :slightly_smiling_face:

ashishkel
2016-09-09 12:24
:slightly_smiling_face:

ashishkel
2016-09-09 12:26
@hgabor - i just did a Find on the protocol spec before i ran my test case. I'm not sure yet. May be this is the reason i m not able to get my chaincode id rite right, when i m invoking from another chaincode.

ashishkel
2016-09-09 12:26
Cant be sure till I test it fully.

lbonniot
2016-09-09 12:58
I can confirm that the parameters does indeed change the chaincode id, at least on the v0.6 branch right now :wink: @ashishkel @hgabor To be honest, I expected the chaincode id to be unique. What if I want to deploy exactly the same code, with the same parameters, as two different chaincodes?

hgabor
2016-09-09 12:59
@lbonniot is that possible? @muralisr

deeflorian
2016-09-09 13:00
checked and possible (if the question is still related to the CCID generation)

muralisr
2016-09-09 13:00
@lbonniot same code, diferent params will result in different ID

muralisr
2016-09-09 13:00
its a new chaincode with new initiazation

deeflorian
2016-09-09 13:00
@lbonniot the deployment can be done by using a dummy parameter, but the CC would need to be prepped

muralisr
2016-09-09 13:00
the new architecture will address lifcycle issues more flexibly

deeflorian
2016-09-09 13:01
on the same topic, CCs still access the ledger as a simple K-V store, right (@hgabor)? so two CC-s sharing the same key names would result in faulty behaviour

hgabor
2016-09-09 13:02
@muralisr if somebody wants to find out the CCID of a specific chaincode with a specific init, what is the specific way for that?

hgabor
2016-09-09 13:02
@deeflorian K-V store, dont you mean the world state?

deeflorian
2016-09-09 13:03
@hgabor yepp

hgabor
2016-09-09 13:03
as I know world state is per chaincode. @muralisr ?

hgabor
2016-09-09 13:03
(I mean, separated)

deeflorian
2016-09-09 13:06
that'd be the ideal imho, but i remember some issue related to this... long time ago though

deeflorian
2016-09-09 13:06
(least this supports that a short changelog is very much in need :D)

hgabor
2016-09-09 13:07
yeah, you are right

hgabor
2016-09-09 13:07
I will write a note to the other maintainers

ashishkel
2016-09-09 13:23
@lbonniot . We are managing with workarounds now,,, Same chaincode , same init for two diff business is managed by keeping them in two different folders - As you notice, the path to the chaincode is also an impacting factor.

ashishkel
2016-09-09 13:32
@hgabor I don't think CCID of a particular chaincode can be retrieved from the Fabric once its deployed. Unless you want to track that deployment transaction. We are planning to do that by maintaining a master chaincode in Fabric who stores it as an inventory - say [ Identifier + Version ] as Key - and CCID as Value. Dont know whether it is practical or not.. yet

kostas
2016-09-09 14:20
Thanks for this.

kostas
2016-09-09 14:21
@kostas uploaded a file: https://hyperledgerproject.slack.com/files/kostas/F2A1GK8HG/_make_unit-test__output.sh and commented: I now get this however.

karn
2016-09-09 15:32
has joined #fabric-dev

kostas
2016-09-09 17:46
`vagrant destroy` + `vagrant up` fixed it BTW.

kostas
2016-09-09 17:46
(I read Greg's email.)

tomrsmith
2016-09-09 19:25
has joined #fabric-dev

hgabor
2016-09-12 09:20
vagrant seems to hang at this:

hgabor
2016-09-12 09:20

ghaskins
2016-09-12 17:46
@hgabor i see that from time to time. I speculate its stuck in the “apt-get upgrade -qq"

ghaskins
2016-09-12 17:46
we are probably best served to get rid of the -qq, or least make it environmental

ghaskins
2016-09-12 17:46
but long story short, I think its transient failures in the ubuntu update process

hgabor
2016-09-12 18:05
@ghaskins: it managed to continue the process so no problem :-)

ghaskins
2016-09-12 18:12
Yeah it seems sometimes it's just super slow

ghaskins
2016-09-12 18:12
If you let it go, it continues eventually


jonathanlevi
2016-09-12 18:15
That’s what my Yogist would have probably said about apt-get.

muralisr
2016-09-12 18:31
I’m trying to make sense of Jenkins behavior … is it me or is it somewhat random ?

muralisr
2016-09-12 18:32
Apart from one goimports failure which is my fault, I’m trying to get https://gerrit.hyperledger.org/r/#/c/999/ thru

muralisr
2016-09-12 18:33
I’m waiting for a reverify to go thru

jonathanlevi
2016-09-12 19:15
@muralisr: done

jonathanlevi
2016-09-12 19:15
[not sure whether it was you or somewhat random though ;-)]

jonathanlevi
2016-09-12 19:16
[The goimport, more likely]

muralisr
2016-09-12 19:16
well, that was the one time clear failure… but others? ….thanks much in anycase @jonathanlevi :slightly_smiling_face:

jonathanlevi
2016-09-12 19:17
We really need to stabilize the tests.

jonathanlevi
2016-09-12 19:17
I’m trying to ‘harden’ these as much as I can (including the requirement of using specific packages everywhere, etc.)

hgabor
2016-09-12 19:17
have you seen that it got +1? :smile:

hgabor
2016-09-12 19:17
from Job Builder

jonathanlevi
2016-09-12 19:17
Non-determinism is the worst

jonathanlevi
2016-09-12 19:18
The Job Builder is great :wink:

muralisr
2016-09-12 19:19
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F2AQNS3PE/pasted_image_at_2016_09_12_03_18_pm.png and commented: looks like got a +1 because the unit-tests passed and the bddtest failure was skipped

skarim
2016-09-12 19:48
has joined #fabric-dev

david.acton
2016-09-12 20:27
Hello. I’m running a peer in mac osX… when I’m setting CORE_VM_ENDPOINT, it does’t seem to update where it tries to deploy.. … has the ENV variable changed?

skarim
2016-09-12 20:31
*Trying to connect Multiple Peers using multiple Membership Service instance* Currently, you can have two peers using the same membership service connect and be able to share the ledger (world state). This works with noops. Now, we have Peer 1 that connects to MS 1 and Peer 2 that connect to MS 2. To get these peers to even connect we had to update the certificates table in eca.db of each respective membership service instance with certificates from other peers. For example, update MS 2 instance with certificate used by Peer 1 and vice versa. Doing this has allowed us to connect the peers together. However, they do not share the same ledger. If we query (Get State) from Peer 1 on a specific key, we get different results compared to when we query from Peer 2. The question is what is necessary for two peers to communicate when they use certificates from different membership services?

jonathanlevi
2016-09-12 20:42
When you ask what is *necessary*, do you mean from a technical point of view, or from a business point of view?

jonathanlevi
2016-09-12 20:42
The main (original) idea is/was to be able to delegate the Membership Services responsibility.

jonathanlevi
2016-09-12 20:43
The ‘challenge’ is to be able to associate the 2 certificates…

jonathanlevi
2016-09-12 20:43
(it’s not really a challenge)

jonathanlevi
2016-09-12 20:43
But that’s what many are/were talking about when it comes to running multiple instances of MS

jonathanlevi
2016-09-12 20:44
That is, how can a validation point ‘respect’ / accept such signed certificates.

jonathanlevi
2016-09-12 20:45
The solution presented (also at the hackfest SF) is some hierarchy of MS… supporting disjoint sets of responsibilities (e.g Oil vs Previous Metals)

jonathanlevi
2016-09-12 20:45
… and...

jonathanlevi
2016-09-12 20:46
the ability for other Members to pre-agree on a set of MS/entities that they’d trust.

david.acton
2016-09-12 22:45
Hi, What’s the recommended way to deploy chaincode, via REST, GRPC or it doesn’t matter?

cbf
2016-09-12 23:59
@david.acton the node SDK is the preferred way, but for development purposes, I would recommend the peer cli method documented here: http://hyperledger-fabric.readthedocs.io/en/latest/Setup/Chaincode-setup/#running-the-cli-or-rest-api

cbf
2016-09-12 23:59
of course, I just noticed that the docs are out of sync (sigh)

david.acton
2016-09-13 00:08
@cbf Thanks for the response. (sigh) is the word. I’m writing my client in GO so I won’t be using the Node SDK for this at the moment. I’ll implement the rest interface then.

cbf
2016-09-13 00:33
ah, you are writing a client in go… interesting

cbf
2016-09-13 00:33
I am pulling out the cli from the peer

cbf
2016-09-13 00:34
the REST API is deprecated

cbf
2016-09-13 00:34
it could be stop-gap, but it isn’t intended to be supported down the road - though we may re-create via loopback on the node sdk

david.acton
2016-09-13 00:39
so if the REST API is depreciated.. what is the replacement?

david.acton
2016-09-13 00:39
@cbf

cbf
2016-09-13 00:40
language-specific sdks

cbf
2016-09-13 00:40
and the cli

cbf
2016-09-13 00:40
the CLI could double as a Go SDK

david.acton
2016-09-13 00:41
but the language specific SDKs will have to communicate with the peer somehow. What is suggested there?

cbf
2016-09-13 00:43
grpc sorry

david.acton
2016-09-13 00:43
ahh cool. :slightly_smiling_face:

cbf
2016-09-13 00:43
you can get a sense by looking at the peer

cbf
2016-09-13 00:44
specifically, peer/chaincode folder

cbf
2016-09-13 00:44
you could probably use some of the same code

david.acton
2016-09-13 00:45
Yeah I’ve been doing that. I got confused at first why the ChaincodeID of one of the messages was a []byte until I read the comment

david.acton
2016-09-13 00:46
I’ll continue down the GRPC road then if you don’t think it’s a bad idea

david.acton
2016-09-13 01:17
@cbf I see the DevOps REST endpoint was depreciated, is the GRPC DevOps one being depreciated too?

cbf
2016-09-13 01:31
well, it’s complicated, but basically no - but it may be refactored

cbf
2016-09-13 01:32
because that code is very tangled

cbf
2016-09-13 01:32
@david.acton ^^

david.acton
2016-09-13 01:34
OK.. Good to know

david.acton
2016-09-13 01:34
And I agree with you

cbf
2016-09-13 01:50
:wink:

mohan
2016-09-13 13:00
has joined #fabric-dev

kostas
2016-09-13 20:31
Following the instructions listed in `devnet-setup.md` to the letter to test out something and when querying with privacy/security on I get this:

kostas
2016-09-13 20:32
Input: `CORE_PEER_ADDRESS=172.17.0.2:30303 CORE_SECURITY_ENABLED=true CORE_SECURITY_PRIVACY=true peer chaincode query -u jim -l golang -n BLOB_GOES_HERE -c '{"Function": "query", "Args": ["a"]}'`

kostas
2016-09-13 20:32
Output: `Error: Error querying chaincode: rpc error: code = 2 desc = "Error:Failed to launch chaincode spec(Error starting container: API error (400): {\"message\":\"starting container with HostConfig was deprecated since v1.10 and removed in v1.12\"}\n)"`

kostas
2016-09-13 20:34
(Forgot to say, Fabric-0.5.)

garisingh
2016-09-13 20:37
@kostas - running in latest Vagrant image?

kostas
2016-09-13 20:38
Working on this with @anya, she tells me that it's an issue with my Docker version. We got this. (I think.)

garisingh
2016-09-13 20:38
that's the issue

garisingh
2016-09-13 20:38
if `docker version` shows 1.12, you are in trouble with v0.5

anya
2016-09-13 20:40
yes

anya
2016-09-13 20:40
that is why i think using `apt-get update` inside our Vagrant install scripts is a horrible idea

anya
2016-09-13 20:40
we need to pick the dependencies and stick with them

anya
2016-09-13 20:41
the Vagrant scripts essentially update EVERYTHING every time you bring up the dev environment which can break us at any point without us even doing anything at all!

anya
2016-09-13 20:41
i am not sure why we are still doing that… but i think we need to pick the versions we use and stick with them

ghaskins
2016-09-13 20:42
@anya note that its not quite that egregious

anya
2016-09-13 20:42
to get around this issue on Fabric05, the only way that i know of how to do this is to *manually* reinstall Docker inside vagrant to 1.11.1

ghaskins
2016-09-13 20:42
yes, it does an apt-get update, but its also against an LTS release which has limits in terms of ABI borkage that is allowed

ghaskins
2016-09-13 20:43
what needs more careful review is any sources of packages that are not part of the official Ubuntu repos, as they may not be as strict

anya
2016-09-13 20:43
ok… but then we still get issues like what Kostas just cited… any way to avoid things like that by setting some of the dependencies?

ghaskins
2016-09-13 20:43
i think that is one of the external deps I mentioned

ghaskins
2016-09-13 20:44
it currently installs the latest from docker

ghaskins
2016-09-13 20:44
so, that needs to be pinned down so its repeatable

anya
2016-09-13 20:44
yes

anya
2016-09-13 20:45
not sure how we would identify all of these external deps. but point is, something like this can happen again and the workaround is pretty annoying

ghaskins
2016-09-13 20:45
yes…just saying, its not the apt-get update/upgrade per se

ghaskins
2016-09-13 20:45
rather, its the unofficial repos

anya
2016-09-13 20:46
i see

ghaskins
2016-09-13 20:46
let me think about it, perhaps I can roll something into the baseimage update I am working on

anya
2016-09-13 20:46
that would be fantastic

anya
2016-09-13 20:47
as the testers are pretty concerned about this too

ghaskins
2016-09-13 20:47
yes

anya
2016-09-13 20:47
given that the env can change while doing test

ghaskins
2016-09-13 20:47
agreed, it needs to be repeatable

silliman
2016-09-13 20:47
@kostas somebody posted this workaround on one of these slack channels a week or so ago, I think it may work for you: Comment out this line `err = client.StartContainer(containerID, hostConfig) ` and add `err = client.StartContainer(containerID, nil)` in core/container/dockercontroller/dockercontroller.go

anya
2016-09-13 20:48
alternatively reinstall Docker to version 1.11.1 from here: http://apt.dockerproject.org/repo/pool/main/d/docker-engine/

garisingh
2016-09-13 20:49
here's the thing - we do want to support Docker 1.12 so we need to be able to test against it. Clearly there was a breaking deprecation between 1.11 and 1.12. We are also going to see this with NodeJS, JVMs, etc.

garisingh
2016-09-13 20:51
and if we are not already, we should be using the official Docker repository as well which will allow you to install specific versions of Docker. You can also just install from tarballs as well

garisingh
2016-09-13 20:52
also - using binary installations is quite simple as well - https://docs.docker.com/engine/installation/binaries/

kostas
2016-09-13 21:22
@silliman: Thanks for the tip, trying it out now. (Anya gave me a great workaround by downgrading to Docker 1.11 as well.)

kostas
2016-09-13 22:15
FWIW, even though I fixed the Docker issue described above, I'm still having trouble deploying chaincode successfully with the fabric-0.5 code. (I'm using the weekend's patch on top of it.)

kostas
2016-09-13 22:15
When querying, I get: `Error: Error querying chaincode: rpc error: code = 2 desc = "Error:Failed to launch chaincode spec(Could not get deployment transaction for aa5389f7dfb9efae379900a41db1503fea2199fe400272b61ac5fe7bd0c6b97cf10ce3aa8dd00cd7626ce02f18accc7e5f2059dae6eb0786838042958352b89fb - LedgerError - ResourceNotFound: ledger: resource not found)"`

kostas
2016-09-13 22:16
Following Anya's advice, I looked into chaincode deployment and indeed it fails:

kostas
2016-09-13 22:16
> 22:14:13.502 [dockercontroller] deployImage -> ERRO 03c Error building images: cannot connect to Docker endpoint > 22:14:13.541 [dockercontroller] Start -> ERRO 03d start-could not recreate container cannot connect to Docker endpoint > 22:14:13.572 [ledger] sendProducerBlockEvent -> ERRO 03e Error unmarshalling deployment transaction for block event: proto: protos.ChaincodeDeploymentSpec: wiretype end group for non-group

anya
2016-09-13 22:36
@kostas did you try running just a membership service and peer processes like i recommended and deploying?? i.e. NOT with Docker containers at first? any luck on that? we have extensively tested the Fabric05 branch just last week…

garisingh
2016-09-13 22:44
@kostas - your Docker daemon is likely not running

garisingh
2016-09-13 22:44
`docker info`

garisingh
2016-09-13 22:44
either that or it is not listening on the tcp port

garisingh
2016-09-13 22:45
actually, my guess it is not running

kostas
2016-09-13 22:49
Hmm, `docker info` output looks good, and I'm setting the `CORE_VM_ENDPOINT` ENV var to the address displayed by `ifconfig docker0`.

garisingh
2016-09-13 22:50
ps -ef |grep docker

garisingh
2016-09-13 22:50
you also need the port?

garisingh
2016-09-13 22:50
might not be bound to TCP port

garisingh
2016-09-13 22:50
`ps -ef|grep docker` - you should see a -H option

garisingh
2016-09-13 22:52
else I say just use the unix socket for the endpoint - I think its the default in the yaml anyway?

garisingh
2016-09-13 22:52
`CORE_VM_ENDPOINT=unix:///var/run/docker.sock`

kostas
2016-09-13 22:55
The `-H` flag is nice. Yeah, the Docker daemon is running normally.

kostas
2016-09-13 22:55
Will go the Unix socket route.

kostas
2016-09-13 23:05
That's a no-go as well, will take a break and revisit this later on.

kostas
2016-09-13 23:05
I'll get to the bottom of this, was just wondering whether I was dealing with a known bug.

hgabor
2016-09-14 10:49
@cbf @baohua and others how do you like it this way? https://gerrit.hyperledger.org/r/#/c/875/

kostas
2016-09-14 12:02
Sorry @anya, just saw that. I switched to `noops` and tried it your way with just one peer (and security/privacy `on`). I get the following error:

kostas
2016-09-14 12:02
`12:00:26.969 [ledger] sendProducerBlockEvent -> ERRO 415 Error unmarshalling deployment transaction for block event: proto: protos.ChaincodeDeploymentSpec: wiretype end group for non-group`

muralisr
2016-09-14 12:04
@kostas that error can be ignored… the fabric wanted to set the huge deploy payload to nil before sending the event out but cannot decrypt

muralisr
2016-09-14 12:04
we should really remove that error

kostas
2016-09-14 12:07
@muralisr: Gotcha.

kostas
2016-09-14 13:10
Problem solved: `rm -rf /var/lib/docker/network` and restarted the daemon.

wlahti
2016-09-14 13:40
has joined #fabric-dev

cbf
2016-09-14 13:44
https://github.com/juju/errgo @hgabor can you please investigate this and let us all know what you think? I would also encourage others to chime in

hgabor
2016-09-14 13:45
I have already linked this some days ago

hgabor
2016-09-14 13:49
I think this could do the same (and even more) as my 'error handling framework' commit. But I am not sure we need this as it turned out most of us suggest keeping error handling very lightweight (e.g. just with the 'native go facilities', error)

hgabor
2016-09-14 13:50

hgabor
2016-09-14 13:52
@cbf with Juju we could have the error call stack, error stacking, error codes, and even more but the question is if we need those :slightly_smiling_face: as I know, most of us says we don't

hgabor
2016-09-14 13:54
the same is true for spacemonkey :space_invader:

cbf
2016-09-14 13:57
At the very least, I think we should start using error codes

hgabor
2016-09-14 13:57
I would go with error codes (as it is a common pattern in go) + stack trace (as it helps a lot)

hgabor
2016-09-14 13:59
@grapebaba said that stack trace should be optional. I think it should be 'mandatory', we should have one general HyperLedger Error type that would be used everywhere in the project (it would have a stacktrace + error code)

hgabor
2016-09-14 14:00
@simon argued about the current usage of errors, and that we should refactor the whole code as we have been misusing golang errors

garisingh
2016-09-14 14:18
I think stack traces should be dumped to file - trace file :wink:

garisingh
2016-09-14 14:18
never propagated up the error handling stack

garisingh
2016-09-14 14:19
we'll need to start separating out "logs" and actually have real log files rather than redirecting stdout and stderr

hgabor
2016-09-14 14:19
but if you log the error in a higher layer how do you get the stack traces?

hgabor
2016-09-14 14:19
I think logging needs to be configurable, where to write it, etc

garisingh
2016-09-14 14:22
well I admit I am not an expert on stack traces with Go - but for example in C++, Java, Node let's say you capture an error - at that point you can log and dump the stack trace and then propagate the error itself forward if you need to (depending on whether you create your own error or whether or not you just pass the error up the stack)

garisingh
2016-09-14 14:23
I think you should be able to log the stack trace wherever / whenever you initially handle the exception instead of having to pass it around. Maybe I am wrong and/or missing something :wink:

hgabor
2016-09-14 14:24
you can log it (e.g. the same way I store it in the error struct) but if the error is propagated to some higher level where you decide that you have to log it, you can only get the actual stack trace, not the stack trace of the code where the error origitanted

hgabor
2016-09-14 14:24
do you see my problem?

garisingh
2016-09-14 14:29
sure - but why not just log the trace at point of initial error capture? why would we decide to dump a trace higher in the stack? But I see your dilemma.

hgabor
2016-09-14 14:32
e.g. "I am a util lib" and I am called by a more complex util lib. and that one is called by some code which decides that the error given by the lib is not fatal. so it logs it. but why should I log it? I do not know how fatal it will be for the caller, I just return the error.

hgabor
2016-09-14 14:47
@garisingh what do you think?

muralisr
2016-09-14 14:50
@hgabor did you see my comment about errors from go routines ? user command gets propagatd to goroutines… user stack fields the error. The stack trace there does not say any thing about the “real” error

muralisr
2016-09-14 14:51
we would also need a disciplined approach to propogate errors

ry
2016-09-14 14:51
@ry has left the channel

hgabor
2016-09-14 14:52
yeah. isn't the problem that errors from go routines are not propagated but just lost?

muralisr
2016-09-14 14:53
yes.

hgabor
2016-09-14 14:53
the trivial good practice would be to somehow channel back those if they are needed

hgabor
2016-09-14 14:54
but I can search for other solutions

hgabor
2016-09-14 14:55

muralisr
2016-09-14 14:58
that would be a nice if we can do it in a way that’d encourage developer discipline

hgabor
2016-09-14 17:22
do you think we can encourage that anyhow? :slightly_smiling_face:

hgabor
2016-09-14 17:27
it feels like a bad practice but we can have a singleton channel in errors.go where errors.fmt(...) could send the errors to

hgabor
2016-09-14 17:29
@muralisr what do you think?

sergeybalashevich
2016-09-14 17:41
There is a question connected to cross-chaincode requests in Fabric. I have chaincodes A and B. Each chaincode has “Invoke” which reads attributes using stub.ReadCertAttribute(“role") Both chaincodes see correct attributes’ values if I send direct requests to these chaincodes. But in case if A tries to call stub.InvokeChaincode on B, in this case first chaincode can read Attributes, but second chaincode has “Error: The certificate can’t be nil.” error message. Does it mean that even if both chaincodes are executed in the same transaction, the SecurityContext is not propagated to B ?

ghaskins
2016-09-14 17:49
@sergeybalashevich i think thats just a bug/limitation of the current impl

ghaskins
2016-09-14 17:50
not something that will never be supported

ghaskins
2016-09-14 17:50
i seem to recall cross-chaincode invoke with security=on is currently broken

ghaskins
2016-09-14 17:50
@muralisr do you know if we carried a JIRA over for it?

sergeybalashevich
2016-09-14 17:52
@ghaskins Thank you!

ganesh47
2016-09-14 17:57
has joined #fabric-dev

muralisr
2016-09-14 18:30
@ghaskins _i seem to recall cross-chaincode invoke with security=on is currently broken_ - correct

muralisr
2016-09-14 18:30
I don’t think we carried over a JIRA

muralisr
2016-09-14 18:31
I’ll open one

garisingh
2016-09-14 19:15
@muralisr - I think there is going to be more work involved in actually dealing with cc to cc communication with the new endorser model

garisingh
2016-09-14 19:15
I would start with that and then add the various tasks

garisingh
2016-09-14 19:15
although I put this at pretty low priority for v1.0.0 initial release :wink:

muralisr
2016-09-14 19:18
@garisingh oh yes. I meant for master to carry over the github issue

cbf
2016-09-15 15:14
with regards to stacktraces, can't we have a logging level for that, and log it where it occurs (along with the error there) and then propogate the error as usual, to be handled (and possibly logged up the stack?

muralisr
2016-09-15 15:55
something like that that user can turn for a deeper debugging. Users _would_ find need to dump the stack to troubleshoot / debug. But having it on all the time would be annoying

cbf
2016-09-15 16:02
agree, but you could tie with debug

muralisr
2016-09-15 16:04
right

muralisr
2016-09-15 16:07
that might be the simplest… one thing, we would get a lot of junk when we just want to troubleshoot error. Another approach could be a trace option ?

zhangsoledad
2016-09-16 07:42
has joined #fabric-dev

rajeshsubhankar
2016-09-16 16:51
has joined #fabric-dev

mikezaccardo
2016-09-16 20:29
hi, i noticed that the `hyperledger/fabric-membersrvc` docker image no longer has a `latest` tag: https://hub.docker.com/r/hyperledger/fabric-membersrvc/tags/

mikezaccardo
2016-09-16 20:29
i have a deployment script that relies on pulling this — is there a way to do this generally?

mikezaccardo
2016-09-16 20:30
currently the tag is `x86_64-0.7.0-SNAPSHOT-5a1c542` but that’s bound to change often, right?

ghaskins
2016-09-16 20:30
I think there is some house cleaning going on…we are working on getting things setup so only releases are published

mikezaccardo
2016-09-16 20:30
thanks @ghaskins — will a `latest` return soon?

ghaskins
2016-09-16 20:30
yes, I that will change, but I think we are not going to publish the -SNAPSHOTS any more

ghaskins
2016-09-16 20:31
yes, it will include latest

ghaskins
2016-09-16 20:31
bear with us

mikezaccardo
2016-09-16 20:31
great! if you happen to remember, could you ping me when this occurs so i can change it back, please?

ghaskins
2016-09-16 20:31
we will soon have the full suite of images (peer, membersrvc, ccenv, etc) all versioned and with :latest, but only for releases

ghaskins
2016-09-16 20:32
we will send out a broadcast in general (ML, slack, etc)

ghaskins
2016-09-16 20:33
@cbf we should probably leave the v0.6.0-preview/latest image?

ghaskins
2016-09-16 20:33
i can manually submit those if the pipeline cant retrigger

mikezaccardo
2016-09-16 20:34
great, thanks for the fast + thorough answer

ghaskins
2016-09-16 20:34
yw

ghaskins
2016-09-16 20:36
@mikezaccardo fwiw, you can build them from source any time

ghaskins
2016-09-16 20:36
not sure this is helpful for your workflow, but I could walk you through it

mikezaccardo
2016-09-16 20:43
@ghaskins good to know, but not ideal for my use case

mikezaccardo
2016-09-16 20:43

cbf
2016-09-16 20:46
@ghaskins @ry yes we need to have a 0.6-preview image and we should have a latest I think

ghaskins
2016-09-16 20:47
@cbf: ill manually build from the tag and put that up there + :latest

cbf
2016-09-16 20:47
thx

ghaskins
2016-09-17 00:07
@mikezaccardo images are back

mikezaccardo
2016-09-17 19:38
fantastic, thanks @ghaskins!

cbf
2016-09-17 21:53
@ghaskins next we should tackle the fabric-src, fabric-ccenv etc ones

cbf
2016-09-17 21:54
presume that these won’t be external to fabric build, but as we have done with baseimage, triggered?

ghaskins
2016-09-17 23:34
I see fabric peer/ccenv/javaenv being coupled to the same release frequency/versioning, but perhaps there other ways to do it

ghaskins
2016-09-17 23:34
Fabric-src doesn't need to be published anywhere. It's an intermediate artifact

ghaskins
2016-09-17 23:35
At least currently

ghaskins
2016-09-17 23:35
But that said: yes, good next steps in general

ghaskins
2016-09-17 23:36
I suppose once the shims are broken out, ccenv/javaenv will follow the releases of the shims

donovanhide
2016-09-18 15:44
has joined #fabric-dev

vmanoria
2016-09-19 11:25
has joined #fabric-dev

mikezaccardo
2016-09-19 22:51
has `membersrvc` usage recently changed? when i attempt to deploy validating peers i’m met with this error: ``` 22:29:14.228 [crypto] RegisterValidator -> INFO 004 Registering validator [test_vp0] with name [test_vp0]... 22:29:14.230 [crypto] Errorf -> ERRO 005 [validator.test_vp0] Failed requesting read certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 22:29:14.230 [crypto] Errorf -> ERRO 006 [validator.test_vp0] Failed requesting ECA certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 22:29:14.230 [crypto] Errorf -> ERRO 007 [validator.test_vp0] Failed getting ECA certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 22:29:14.230 [crypto] Errorf -> ERRO 008 [validator.test_vp0] Failed retrieving ECA certs chain [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 22:29:14.230 [crypto] Errorf -> ERRO 009 [validator.test_vp0] Failed registering node crypto engine [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 22:29:14.230 [crypto] Errorf -> ERRO 00a [validator.test_vp0] Failed registering peer [test_vp0]: [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure] 22:29:14.230 [crypto] Errorf -> ERRO 00b [validator.test_vp0] Failed registering [test_vp0]: [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure] 22:29:14.230 [crypto] RegisterValidator -> ERRO 00c Failed registering validator [test_vp0] with name [test_vp0] [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure 2016/09/19 22:29:14 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp <IP hidden>:50051: getsockopt: connection refused"; Reconnecting to {"<IP hidden>:50051" <nil>} 2016/09/19 22:29:14 Failed to dial <IP hidden>:50051: grpc: the connection is closing; please retry. ``` i currently deploy `membersrvc` this way: ``` sudo docker run --name=membersrvc \ --restart=unless-stopped \ -i \ -p 50051:50051 \ -e CORE_LOGGING_LEVEL=info \ hyperledger/fabric-membersrvc:latest membersrvc ```

garisingh
2016-09-20 12:01
@mikezaccardo - by default membersrv now listens on port 7054

c0rwin
2016-09-20 13:53
has joined #fabric-dev

c0rwin
2016-09-20 13:59
Hi, I’m working w/ IBM Haifa team on gossip protocol implementation. Overall architecture consists on different modules and there are 3 people in our team working on each of these modules independently. Now, there is a dependency between these modules and we need somehow to propagate changes and being able to update source code to see those changes. That normally I’d do is creating a feature branch for gossip component. However I’m not very sure how to handle such situation in `fabric` project. What is the preferred pattern to handle this?

c0rwin
2016-09-20 13:59
^^^@here:

yacovm
2016-09-20 14:20
@cbf @tuand you got any idea about c0rwin's question?

c0rwin
2016-09-20 14:33
Is there such a thing like a `feature branch`?

cbf
2016-09-20 14:37
@c0rwin yes, we have a couple - basically, the maintainers are the guardians of adding new ones so we don’t have too many

c0rwin
2016-09-20 14:38
@cbf: So to add a new `feature branch` I have to contact the maintainer each time?

cbf
2016-09-20 14:39
ask on #fabric-maintainers and provide an explanation/justification

c0rwin
2016-09-20 14:39
w/ GH I could have to fork and continue to work under my "`namespace`”, while I’m not 100% certain how to handle it w/ gerrit model

cbf
2016-09-20 14:40
I would also ask why you cannot just check things in periodically on the convergence branch

cbf
2016-09-20 14:40
it isn’t cool to have a huge patch to merge, regardless of where it came from

yacovm
2016-09-20 14:40
But, only maintainers can merge stuff into the convergence branch, right?

cbf
2016-09-20 14:41
I was lamenting this https://gerrit.hyperledger.org/r/#/c/1061/ this morning

yacovm
2016-09-20 14:41
so, if we have `n` people working on the same feature- how can we collaborate in the gerrit source control?

yacovm
2016-09-20 14:41
that's mine...

cbf
2016-09-20 14:41
already 4090 loc

cbf
2016-09-20 14:41
right

c0rwin
2016-09-20 14:41
yeah, to have change propagated down the road I need change to be merged

cbf
2016-09-20 14:41
that’s like a weekend’s work to review

cbf
2016-09-20 14:41
maybe more

yacovm
2016-09-20 14:41
why were you lamenting?

yacovm
2016-09-20 14:41
oh

cbf
2016-09-20 14:42
changesets should be small

cbf
2016-09-20 14:42
like <250loc - provide coherence and tests

cbf
2016-09-20 14:42
they can be merged serially if that is needed

cbf
2016-09-20 14:42
occasionally we can tolerate larger ones but seriously

yacovm
2016-09-20 14:44
thing is- lets say I append commits to the convergence all the time, ok?

yacovm
2016-09-20 14:44
now, for a team-mate of mine to pull this code, someone from the maintainers needs to merge it, but in the meantime we're "stuck"

yacovm
2016-09-20 14:46
BTW that's 3.5K LOC, the protobuff code that was generated isn't mine :slightly_smiling_face:

c0rwin
2016-09-20 14:46
and if code to be merged still has nothing to do with the `fabric`, since module divided in packages and these packages are dependant each other and maybe something else

c0rwin
2016-09-20 14:47
more concrete in `1061` there is a code which takes care of gossip discovery, which finished, however out of gossip context it’s meaningless, why one would take care and merge?

c0rwin
2016-09-20 14:49
from other side for me to continue to work and take gossip impl to next level I do have to be able to see this code

c0rwin
2016-09-20 14:49
so I do see how it could work w/ `feature branch`

c0rwin
2016-09-20 14:49
and I completely lost in how to manage it w/ gerrit

c0rwin
2016-09-20 14:50
and then I say `feature branch` I mean the exclusive feature branch

ghaskins
2016-09-20 14:50
two basic comments: its still just git….you can for instance collaborate with someone in a GH fork if you want

ghaskins
2016-09-20 14:51
to do it in gerrit, you would need to lobby the maintainers/community to propose a new feature branch

ghaskins
2016-09-20 14:51
but we want to keep these to a minimum

c0rwin
2016-09-20 14:51
yeah, my understanding that we would like to avoid of developing in parallel within GH

ghaskins
2016-09-20 14:51
things work best if there are fewer branches with small, frequent commits

c0rwin
2016-09-20 14:51
I’m positive about small commits

ghaskins
2016-09-20 14:52
doing anything else impacts the effectiveness of continuous-integration and other related benefits

c0rwin
2016-09-20 14:52
not sure how it works w/ several collaborators which needs to share theirs work on daily basis

ghaskins
2016-09-20 14:52
well, something on gerrit has several properties: CI verification and review

ghaskins
2016-09-20 14:53
if you dont care about CI verification and review, do it in a private branch

ghaskins
2016-09-20 14:53
(or fork, whatever works for your collaborators)

yacovm
2016-09-20 14:53
how can we have a private branch?

yacovm
2016-09-20 14:53
in gerrit?

ghaskins
2016-09-20 14:53
its just git

ghaskins
2016-09-20 14:53
it doesnt need to be in gerrit…putting it in gerrit just exposes the CI/review mechanism

ghaskins
2016-09-20 14:54
like I said, still ideal to have 1 branch in gerrit where people submit small/frequent commits…as it has maximum exposure/integration/verification

yacovm
2016-09-20 14:54
I don't think we have permissions to create a branch in the "gerrit" host endpoint

ghaskins
2016-09-20 14:54
im not saying you do

yacovm
2016-09-20 14:55
oh ok

ghaskins
2016-09-20 14:55
im saying, you dont technically need it

c0rwin
2016-09-20 14:55
I wish I could have my feature branch in gerrit to keep delivering small commits and still be able to collaborate

ghaskins
2016-09-20 14:55
again, delivering small commits and collaboration are not what gerrit provides though

ghaskins
2016-09-20 14:55
it provides integration and review

ghaskins
2016-09-20 14:56
you can do commits and collaboration elsewhere

ghaskins
2016-09-20 14:56
(I am not suggesting you should do this, just making sure its clear)

c0rwin
2016-09-20 14:56
also taking private branches in GH or other places will bring potential danger of divergence and possibility of override

ghaskins
2016-09-20 14:56
precisely

ghaskins
2016-09-20 14:56
but a branch does too

c0rwin
2016-09-20 14:56
it least branch is transparent for everyone

ghaskins
2016-09-20 14:56
the only true way to alleviate divergence risk is to not branch at all

yacovm
2016-09-20 14:57
ghaskins, technically we do- because we're developing a component that is from one hand very big and complex, and on the other hand- doesn't have much "surface area" that connects to the fabric project. ..

c0rwin
2016-09-20 14:57
and also kept in the sample place in gerrit so it much easier to merge and keep things converged

ghaskins
2016-09-20 14:57
ok, step back for a second

ghaskins
2016-09-20 14:58
gerrit is just a git repository that happens to have a commit-gate (via review) and a CI infrastructure, right

yacovm
2016-09-20 14:58
yes

ghaskins
2016-09-20 14:59
any branch, for any reason, reduces some degree of integration validation

ghaskins
2016-09-20 14:59
but that said, there are a few legitimate reasons to want to branch

ghaskins
2016-09-20 14:59
now its a question of: what is the best model for that branch

ghaskins
2016-09-20 15:00
something major, like features/convergence, was successfully lobbied to support as a first class branch because the project warranted it would benefit from its own review/validation process during its development

ghaskins
2016-09-20 15:01
if you think this project qualifies as well, lobby to have this project added to features/* too

ghaskins
2016-09-20 15:01
if its smaller in scale, perhaps another mechanism is a better alternative

yacovm
2016-09-20 15:01
So you propose lobbying for our own branch then?

yacovm
2016-09-20 15:02
if we need, that is?

ghaskins
2016-09-20 15:02
but the main point is that, you dont need it for collab, you need it if your branch needs per patch review and CI

ghaskins
2016-09-20 15:02
im not saying that, I dont know the nature of your project

yacovm
2016-09-20 15:02
but- we do need it for collab, if we need to be able to merge code without waiting for a maintainer to review and then merge, don't we?

ghaskins
2016-09-20 15:02
that is just what I would consider in trying to decide

ghaskins
2016-09-20 15:03
I would say its the opposite

ghaskins
2016-09-20 15:03
you _dont_ want it to be in gerrit if you dont want to wait for maintainer approval

ghaskins
2016-09-20 15:03
going through gerrit will mean each patch needs to be reviewed

yacovm
2016-09-20 15:03
ok I see. @mandler

ghaskins
2016-09-20 15:03
(again, i am not saying this is a good idea, just giving the facts on the differences)

yacovm
2016-09-20 15:04
I understand, thanks

ghaskins
2016-09-20 15:04
np

ghaskins
2016-09-20 15:05
whatever mechanism you decide, I would strive for minimal divergence from the master branch though

ghaskins
2016-09-20 15:05
(there are different ways to achieve this)

c0rwin
2016-09-20 15:06
one thing which still not clear for me

ghaskins
2016-09-20 15:06
small overall change, frequent upstreaming, frequent merging, etc

c0rwin
2016-09-20 15:06
working on private branch/git will contradict the main motto of small changes and frequent updates

yacovm
2016-09-20 15:06
+ frequent CRs, right?

ghaskins
2016-09-20 15:07
technically _any_ branch does that

ghaskins
2016-09-20 15:07
public or otherwise

ghaskins
2016-09-20 15:07
like I said: in the ideal: no branches, small/frequent patches = simplicity

ghaskins
2016-09-20 15:07
everything flows through continuous integration, divergence risk = 0

ghaskins
2016-09-20 15:08
in the real world, this isnt always practical

ghaskins
2016-09-20 15:08
(for instance, fabric-next is a disruptive update)

ghaskins
2016-09-20 15:08
but we should try to minimize those instances

ghaskins
2016-09-20 15:09
case in point, features/convergence and master already do not merge without conflict

ghaskins
2016-09-20 15:09
even though they are both public, both go through review, and both have CI within their respective branches

c0rwin
2016-09-20 15:11
`feature branch` development model is aiming for simplicity and cleanses of the process allowing to move in parallel while keeping transparency of the development process

ghaskins
2016-09-20 15:12
sorry to sound like a broken record: but it buys you patch reviews and integration with the current CI pipeline

ghaskins
2016-09-20 15:12
nothing more

ghaskins
2016-09-20 15:12
for instance, a GH fork is just as “transparent"

ghaskins
2016-09-20 15:12
git in general allows you to move in parallel

ghaskins
2016-09-20 15:12
etc

c0rwin
2016-09-20 15:13
so what is the preferred way to go?

ghaskins
2016-09-20 15:13
so now its just a matter of “what is discoverable” in terms of that transparecny

c0rwin
2016-09-20 15:13
fork on GH?

c0rwin
2016-09-20 15:13
is GH up-to-date w/ gerrit?

ghaskins
2016-09-20 15:13
to be clear: I am not advocating one way or the other

c0rwin
2016-09-20 15:13
yeah-yeah, I understand

c0rwin
2016-09-20 15:14
but right now we are asking purely due to practical reasons

ghaskins
2016-09-20 15:14
all I am saying is: 1) there should be a high threshold for deciding to branch development, and 2) there are specific reasons for wanting that branch to be on gerrit

ghaskins
2016-09-20 15:14
that would include review/CI

ghaskins
2016-09-20 15:14
but not necessarily transparency or collab

c0rwin
2016-09-20 15:15
Having team of 3 developers working on same feature which divided nicely into de-coupled but dependent modules

ghaskins
2016-09-20 15:15
after considering all that, you still think the best solution is a feature branch in gerrit, just lobby for it

c0rwin
2016-09-20 15:15
what should be a “kosher” way to handle the situation preserving project development policies?

ghaskins
2016-09-20 15:16
i think the project is still too green to have precedent :wink:

ghaskins
2016-09-20 15:16
but this might be one of the ones that sets it

ghaskins
2016-09-20 15:17
(to answer your question about GH, its mirrored instantaneously after merging in gerrit)

ghaskins
2016-09-20 15:17
so, I personally have no problem with collab happening on GH forks

ghaskins
2016-09-20 15:17
not sure what others feel

ghaskins
2016-09-20 15:18
I do agree that we should probably have some stated recommendations in this regard though so people can discover each others work

c0rwin
2016-09-20 15:18
What is the way here to raise the lobby? Or ask what majority thinks should be done here?

ghaskins
2016-09-20 15:18
(e.g. whether its gerrit feature branches, GH forks, both, something else, etc)

c0rwin
2016-09-20 15:19
for example in ASF there is a mailing list policies to initiate voting procedure

ghaskins
2016-09-20 15:19
as a general rule, I try to do most formal things via the ML first, and then link the archive to slack

c0rwin
2016-09-20 15:19
not sure how to such cases handled here

ghaskins
2016-09-20 15:20
so, for this case, I might be inclined to start a thread on fabric-discuss, and then link it here

ghaskins
2016-09-20 15:20
"Subject: propose features/foo” or whatever

yacovm
2016-09-20 15:20
there is a fabric-discuss channel?

ghaskins
2016-09-20 15:20
ML

ghaskins
2016-09-20 15:20
but yes

ghaskins
2016-09-20 15:21
sorry: “hyperledger-fabric"


ghaskins
2016-09-20 15:21
i was remembering it wrong

ghaskins
2016-09-20 15:26
you guys probably already know this, but just to be complete: for any given ML, there is an archive page…so after making an announcement there, I grab a link from the archive like this:


ghaskins
2016-09-20 15:26
and paste it here

ghaskins
2016-09-20 15:26
that would be my recommended way to ask about this

c0rwin
2016-09-20 15:42
thanks, definitely will follow your recommendation

mikezaccardo
2016-09-20 16:06
thanks @garisingh, and i found a complete(?) set of changes here: https://github.com/hyperledger/fabric/commit/dad7a9d35c64764a91da823137b3d6d63218a6b2


cbf
2016-09-20 18:17
@c0rwin it is important that we not have extended collaboration outside the project. As @ghaskins says, it is just git. That said, as open source we want to be inclusive and transparent. No one wants to review some monster patchset, Hence the need for small, incremental, self-contained changes. You can indeed collaborate in this model. This is how open source works. Do you need to sometimes wait to get something merged? Yes. However, there are things you can and should do to minimize that wait. Small patches with tests that can be easily verified and reviewed are more likely to be merged quickly.

cbf
2016-09-20 18:17
you can also serialize patchsets

cbf
2016-09-20 18:17
so, I can create new changesets from subsequent commits that build off one another

cbf
2016-09-20 18:18
they need to be merged in order, but gerrit manages that

cbf
2016-09-20 18:18
if you want to collaborate with someone else, they can checkout your patch and build off of that

cbf
2016-09-20 18:19
submit a new changeset - again they need to be serialized, keeping small and self-contained ensures speedy review

bsmita
2016-09-20 18:31
@ghaskins - we were able to build peer and membersrvc images on Power, but having a failure with unit-test.

bsmita
2016-09-20 18:31
```Running tests... ? http://github.com/hyperledger/fabric/bddtests/chaincode/go/table [no test files] ok http://github.com/hyperledger/fabric/bddtests/syschaincode/noop 0.036s coverage: 71.0% of statements ? http://github.com/hyperledger/fabric/consensus [no test files] ? http://github.com/hyperledger/fabric/consensus/controller [no test files] ok http://github.com/hyperledger/fabric/consensus/executor 0.040s coverage: 79.7% of statements ok http://github.com/hyperledger/fabric/consensus/helper 0.036s coverage: 0.5% of statements ok http://github.com/hyperledger/fabric/consensus/helper/persist 0.008s coverage: 0.0% of statements ? http://github.com/hyperledger/fabric/consensus/noops [no test files] ok http://github.com/hyperledger/fabric/consensus/pbft 73.714s coverage: 80.2% of statements ok http://github.com/hyperledger/fabric/consensus/util 0.187s coverage: 88.9% of statements ok http://github.com/hyperledger/fabric/consensus/util/events 0.209s coverage: 91.2% of statements ok http://github.com/hyperledger/fabric/core 0.026s coverage: 3.3% of statements ok http://github.com/hyperledger/fabric/core/chaincode 384.829s coverage: 61.6% of statements ? http://github.com/hyperledger/fabric/core/chaincode/platforms [no test files] ? http://github.com/hyperledger/fabric/core/chaincode/platforms/car [no test files] 2016/09/19 14:47:40 setting Number of procs to -1, was 8 buildChaincodeContainerUsingDockerfilePackageBytes: vmName : %s c54f83ff2d38a4b9ebf0e7ea1ce35e2022c8144048a664e89bb2a7d43c2f6df063703721c804eef8a53a91e3f74f902fdd7b8e75bc1c5f16b6eba079db4cc55f buildChaincodeContainerUsingDockerfilePackageBytes: vmName : %s c54f83ff2d38a4b9ebf0e7ea1ce35e2022c8144048a664e89bb2a7d43c2f6df063703721c804eef8a53a91e3f74f902fdd7b8e75bc1c5f16b6eba079db4cc55f 2016/09/19 14:47:41 Failed Chaincode docker build: Step 0 : FROM hyperledger/fabric-ccenv:ppc64le-0.7.0-SNAPSHOT-02a123c ---> 42d79a1dd176 Step 1 : COPY package.car /tmp/package.car ---> Using cache ---> f935070b1590 Step 2 : RUN chaintool buildcar /tmp/package.car -o $GOPATH/bin/c54f83ff2d38a4b9ebf0e7ea1ce35e2022c8144048a664e89bb2a7d43c2f6df063703721c804eef8a53a91e3f74f902fdd7b8e75bc1c5f16b6eba079db4cc55f && rm /tmp/package.car ---> Running in 389d42f9efff ^[[91mUnrecognized option: -client Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ^[[0m --- FAIL: TestCar_BuildImage (0.72s) car_test.go:50: chaincodePath is /root/git/src/github.com/hyperledger/fabric/core/chaincode/platforms/car/test/org.hyperledger.chaincode.example02-0.1-SNAPSHOT.car car_test.go:54: Error building Chaincode container: The command [/bin/sh -c chaintool buildcar /tmp/package.car -o $GOPATH/bin/c54f83ff2d38a4b9ebf0e7ea1ce35e2022c8144048a664e89bb2a7d43c2f6df063703721c804eef8a53a91e3f74f902fdd7b8e75bc1c5f16b6eba079db4cc55f && rm /tmp/package.car] returned a non-zero code: 1 FAIL coverage: 0.0% of statements FAIL http://github.com/hyperledger/fabric/core/chaincode/platforms/car/test 0.759s error: exit status 1 panic: EOF ```

bsmita
2016-09-20 18:33
The branch we used is Srirama's branch which is v0.6 code plus a patch to use the correct Power open-jdk version

bsmita
2016-09-20 18:34
Could you please check to see if there is any obvious problem like chaincodePath is wrong ?

ghaskins
2016-09-20 19:23
@c0rwin adding to @cbf’s point, what I typically do is manage a pipeline of patches with stgit

ghaskins
2016-09-20 19:24
so I might have 10-15 patches in queue, the first 5 are pushed to gerrit awaiting review, the bottom 10 are under active development

ghaskins
2016-09-20 19:24
i incrementally push the patches to gerrit as they mature

ghaskins
2016-09-20 19:25
(those numbers are probably on the extreme side…i am typically working with about 3-6 patches at a time

ghaskins
2016-09-20 19:25
but you can see this in action with this https://gerrit.hyperledger.org/r/#/c/1143/

ghaskins
2016-09-20 19:26
(look at the “Submitted together”)

ghaskins
2016-09-20 19:26
they weren’t actually submitted together, but they do stack that way in my queue

ghaskins
2016-09-20 19:27
if someone wanted to collaborate with me, they could click that “Download” tab in the upper right to check out my “branch"

ghaskins
2016-09-20 19:29
@bsmita regarding the power problem, it sounds like some kind of incompatibility with java

ghaskins
2016-09-20 19:29
do you know what JRE is installed in that environment?

ghaskins
2016-09-20 19:29
I know @bcbrock ran into some limitations with IBM-java

ghaskins
2016-09-20 19:30
I didnt think it was related to the -client flag, but perhaps it was

ghaskins
2016-09-20 19:30
in any case, his problem went away when he switched to oracle

ghaskins
2016-09-20 19:30
(IIRC)

bsmita
2016-09-20 19:32
@ghaskins , in docker file we are installing openjdk-8-jdk, have to see the output to see which version that is. Do you remember if the problem that Bishop was discussed on one of these channels?

ghaskins
2016-09-20 19:36
it almost certainly was on slack and it most definitely has been culled by the 10k limit at this point

ghaskins
2016-09-20 19:36
heh

ghaskins
2016-09-20 19:36
it was months ago

bsmita
2016-09-20 19:36
Ok..I will try to contact Bishop internally

ghaskins
2016-09-20 19:36
ok

bsmita
2016-09-20 19:36
Thank you!

ghaskins
2016-09-20 19:37
no problem, let me know what you find out

bsmita
2016-09-20 19:37
sure

ghaskins
2016-09-20 19:37
(id be surprised if there was a material difference in the openjdk-8 on x86 vs ppcle though

ghaskins
2016-09-20 19:38
in his case, he was using a self-provisioned system and was doing the JRE install from a completely different repo

bsmita
2016-09-20 19:38
Oh! ok

ghaskins
2016-09-20 19:41
@bsmita for some background, the “chaintool” binary is a .jar with a bash script preamble

ghaskins
2016-09-20 19:42
the bash script launches the jvm onto itself (so it runs the .jar portion)

ghaskins
2016-09-20 19:42
it seems from the error that the preamble is invoking a “-client” switch on the JVM which isnt supported for whatever reason on the power environment you are running it on

bsmita
2016-09-20 19:43
Ok, makes sense, can I run it locally and see if it works or not?

ghaskins
2016-09-20 19:43
what I am not sure is: is power running a conditional the causes the -client switch to only be added in power, or is the -client switch added universally but the power environment doesnt support it

ghaskins
2016-09-20 19:43
of course

ghaskins
2016-09-20 19:43
standby for instructions

bsmita
2016-09-20 19:43
thanks!

ghaskins
2016-09-20 19:44

ghaskins
2016-09-20 19:44
make it executable, and then try to run it

ghaskins
2016-09-20 19:44
it will require standard JRE on the path

bsmita
2016-09-20 19:44
ok

bsmita
2016-09-20 19:47
```$>./chaintool Unrecognized option: -client Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ```

bsmita
2016-09-20 19:47
```$>java -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~15.10.1-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) ```

ghaskins
2016-09-20 19:47
well, at least its reproducible, heh

bsmita
2016-09-20 19:48
Right :slightly_smiling_face:

ghaskins
2016-09-20 19:48
its using -client from here


ghaskins
2016-09-20 19:48
what happens if you just run “java -client"

bsmita
2016-09-20 19:49
```$>java -client Unrecognized option: -client Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ```

ghaskins
2016-09-20 19:50
vagrant@hyperledger-devenv:v0.1.0-3e226e4:/opt/gopath/src/github.com/hyperledger/fabric$ java -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

ghaskins
2016-09-20 19:51
so weird, identical versions

ghaskins
2016-09-20 19:51
it works on vagrant/14.04/x86 though

bsmita
2016-09-20 19:52
right

ghaskins
2016-09-20 19:52
thats a head scratcher

ghaskins
2016-09-20 19:52
it seems theres some anecdotal evidence that the switch might be a no-op

ghaskins
2016-09-20 19:52
so, worst case, perhaps i can elide it from the preamble

ghaskins
2016-09-20 19:53
(I didnt write the code that generates the preamble, so its not 100% trivial)

ghaskins
2016-09-20 19:53
but its not rocket science either

ghaskins
2016-09-20 19:54
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F2DSK9X1N/-.pl and commented: “man java” sez

ghaskins
2016-09-20 19:55
my guess, without googling, is that someone deprecated -client some time back and the ppc team was more aggressive in cleaning it up

c0rwin
2016-09-20 19:57
@cbf @ghaskins again I’m in favour of working w/ small change sets and small patches, but, this should work in case of completely new feature?

c0rwin
2016-09-20 19:58
will it be acceptable to introduce new change set for merge while it still not related to the whole picture?

ghaskins
2016-09-20 19:58
@c0rwin: if it can be decomposed into a series of steps that stand on their own, I do not see why not

ghaskins
2016-09-20 19:58
just tag it with [WIP] (work in progress)

ghaskins
2016-09-20 19:58
then people will understand that its not ready for merging

c0rwin
2016-09-20 19:59
for example, while writing gossip, we have a discovery and communication module, than main gossip protocol, next state replication

c0rwin
2016-09-20 19:59
no-no

c0rwin
2016-09-20 19:59
but I do want to merge

c0rwin
2016-09-20 19:59
we are 3 people

c0rwin
2016-09-20 19:59
if change is not merged other person is not able to move forward?

ghaskins
2016-09-20 20:00
as a general rule of thumb, each patch should be an atomic changeset that at least doesnt break things

c0rwin
2016-09-20 20:00
I need changes to be propagate so other team members will be able to continue

c0rwin
2016-09-20 20:00
k

c0rwin
2016-09-20 20:00
so for concerete example

c0rwin
2016-09-20 20:00
say we have discovery and communication completed

c0rwin
2016-09-20 20:01
both pretty self contained and small changes

c0rwin
2016-09-20 20:01
also not dependant w/ each

c0rwin
2016-09-20 20:01
shall we decompose 1061 to have these two independently introduced for merge?

ghaskins
2016-09-20 20:01
looks

ghaskins
2016-09-20 20:02
its always a judgement call

ghaskins
2016-09-20 20:03
I am personally ok with a patch that moves the ball forward without it necessarily being the whole kit

ghaskins
2016-09-20 20:04
e.g. if you had one patch that “adds discovery substrate” and another that “adds communication substrate” and explain that “this will be used later when we add XXXX”, I think thats fine

ghaskins
2016-09-20 20:04
the smaller the patch, the more likely you will find willing reviewers

c0rwin
2016-09-20 20:05
k, I see

ghaskins
2016-09-20 20:05
as long as the tree isnt broken at each patch, a partial conversion is ok

c0rwin
2016-09-20 20:05
make sense

c0rwin
2016-09-20 20:06
will check how to work it out w/ @yacovm and @gennady.laventman

ghaskins
2016-09-20 20:09
as an aside, when adding something that isn’t necessarily “turned on” yet, it would still be ideal if there is a way to verify its correctness (e.g. adding unit test coverage for the “vestige”) is still advised

ghaskins
2016-09-20 20:10
if you dont already, i highly recommend looking into using something like stgit…then you can move up and down your stack with ease, refining each patch as you go

bsmita
2016-09-20 20:10
@ghaskins - not sure why java -client option worked before on Power, but do you think removing the flag from the test is an option?

ghaskins
2016-09-20 20:11
@bsmita to be clear, its the tool itself…the test is just invoking the tool, but yes

ghaskins
2016-09-20 20:11
it should be possible

ghaskins
2016-09-20 20:11
the biggest roadblock is I am using an upstream plugin to generate the preamble so I will have to fork it

ghaskins
2016-09-20 20:12
(not a big deal, but not as trivial as a local patch)

ghaskins
2016-09-20 20:12
actually, i should say I _may_ have to fork it

ghaskins
2016-09-20 20:12
not sure, let me look into it

bsmita
2016-09-20 20:12
Ok...thanks!

ghaskins
2016-09-20 20:13
@bsmita would it be possible to check with oracle JRE?

ghaskins
2016-09-20 20:13
im just curious

bsmita
2016-09-20 20:14
I can check...

harrijk
2016-09-20 20:16
@bsmita @ghaskins fwiw... i was able run java -client within a docker container instance of the hyperledger/fabric-ccenv docker image (used for the TestCar_BuildImage test) on the s390x platform and did not receive the "Unrecognized option" error message. Worked just fine. So add that to the mystery. :slightly_smiling_face: fyi... java -version responds with: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14) OpenJDK 64-Bit Zero VM (build 25.91-b14, interpreted mode)

ghaskins
2016-09-20 20:17
@harrijk good datapoint, thanks

harrijk
2016-09-20 20:17
yqw

ghaskins
2016-09-20 20:17
(it works on x86 too..not sure why P is acting persnickety

harrijk
2016-09-20 20:17
weird

harrijk
2016-09-20 20:17
another "sweet mystery of life" :slightly_smiling_face:

ghaskins
2016-09-20 20:18
it would make more sense if there was variance in the JVM installed

harrijk
2016-09-20 20:18
yep

ghaskins
2016-09-20 20:19
while I have you @harrijk and @bsmita: one thing that we will have to deal with in the very near future is the baseimage

ghaskins
2016-09-20 20:19
in the current repo, P/Z are relatively insulated from my (in)ability to keep the baseimage pipeline populated with the right $arch-$version images

ghaskins
2016-09-20 20:20
because, if the build finds they are missing, it will just compile it locally

ghaskins
2016-09-20 20:20
but as of right now, that is going away soon

ghaskins
2016-09-20 20:21
so, what the means is we need to either a) accept P/Z will be broken soon, b) get P/Z looped into the jenkins baseimage pipeline, or c) come up with a contingent build mechanism similar to how mainline does it now

ghaskins
2016-09-20 20:21
i assume (a) is unacceptable

ghaskins
2016-09-20 20:21
(b) is my preference

harrijk
2016-09-20 20:21
i am working with ramesh to try and get z back into the jenkins pipeline

ghaskins
2016-09-20 20:22
id prefer not to do (c) because its hacky/fragile, but we can if (b) ends up being a problem

ghaskins
2016-09-20 20:22
ok, good

harrijk
2016-09-20 20:22
@ramesh ^^

ghaskins
2016-09-20 20:22
my hope is that we can build such a reliable (b) that its not an issue

harrijk
2016-09-20 20:22
yeah

harrijk
2016-09-20 20:22
i still need to find out what system is being used to build the z images.

bsmita
2016-09-20 20:22
We are also trying to have docker images uploaded to docker hub as soon as possible

harrijk
2016-09-20 20:23
and get that tied into the pipeline

ghaskins
2016-09-20 20:23
@bsmita that will be something we can integrate with what is already going on

bsmita
2016-09-20 20:23
Right, Ramesh made changes for Power and trying to get a clean build

ghaskins
2016-09-20 20:23
ok, cool

harrijk
2016-09-20 20:24
for now... the java shim build is bypassed for the p and z platforms

ghaskins
2016-09-20 20:24
that makes sense

ghaskins
2016-09-20 20:25
in fact, it would be nice if we could modularize the build in general

ghaskins
2016-09-20 20:25
though some of that will happen naturally as things like the shims are broken out

harrijk
2016-09-20 20:25
i agree

ramesh
2016-09-20 20:26
sure @harrijk : will enable z build but we have to make sure all unit-tests works as expected in build machines

harrijk
2016-09-20 20:26
the same goes for all platforms

harrijk
2016-09-20 20:27
in theory all unit tests would have been successfully run before merging into the codebase

david.acton
2016-09-20 20:44
hey gang… I have a question… I have a validating peer 0 (VP0). I deploy chaincode to VP0 and everything works lovely! I create another validating peer (VP1) but when I try and query the chaincode I deployed to VP0 on VP1, it has not replicated. Is this expected behaviour? I would expect that it would catch up correct?

yacovm
2016-09-20 20:44
I still think we need our own private branch, otherwise we won't be able to collaborate because we live in a too different TZ + we work on Sundays and there is no maintainer available to merge the feature_convergence branch or any other branch. @c0rwin

bsmita
2016-09-20 20:49
@ghaskins could you please let me know if you have a version of chaintool that you want me to try, mean while I will look into IBM Java and see if it's any different

ghaskins
2016-09-20 20:51
@yacovm with the caveat that I am not saying one way or the other: note that you dont need a merge to collaborate via gerrit…each “PR” is effectively its own branch

ghaskins
2016-09-20 20:52
and anyone can create a PR

ghaskins
2016-09-20 20:52
(just look at the “Downloads” tab in the upper right for any PR…it has branch instructions

ghaskins
2016-09-20 20:52
so review/merge is not required

ghaskins
2016-09-20 20:52
(for other people to collab on your work, i mean)

yacovm
2016-09-20 20:56
that's the problem. every PR is its own branch. how does squad member A update code that squad member B wrote, and have squad member B "pull" this code to himself?

yacovm
2016-09-20 21:00
let's say I created `[/61/1061/27]` and c0rwin wants to add documentation because I was too lazy, he needs now to pull this branch, add some stuff of its own and then he has to push a new branch, which will be something like `[/61/1062/1]`, and then I'll need to pull this to continue from his code, right? it's clumsy...

ghaskins
2016-09-20 21:07
its just a branch

ghaskins
2016-09-20 21:07
theres 600 ways to do this

ghaskins
2016-09-20 21:07
and it depends on what you want to accomplish

ghaskins
2016-09-20 21:09
if you are collaborating with someone, there will be a degree of pushing and pulling between collaborators no matter how you do it

ghaskins
2016-09-20 21:09
now its just a matter of how/where

yacovm
2016-09-20 21:10
maybe there are, but surely you understand that the easiest mode of work is to have a private branch that we continuously merge and append to, rather than have tons of branches that are created from gerrit PRs, that we need to somehow git-stash, git checkout\pull other branches, etc.

ghaskins
2016-09-20 21:10
of course…i was the one that suggested that as an option to being with :wink:

ghaskins
2016-09-20 21:11
IIUC, the conversation started with the pondering of whether a gerrit branch could be created for the purposes of collaboration

ghaskins
2016-09-20 21:12
and I pointed out that collaboration is not predicated on gerrit, though “branching” in general has its own set of risks

ghaskins
2016-09-20 21:12
thats all

yacovm
2016-09-20 21:12
ok

ghaskins
2016-09-20 21:13
if I needed fast back and forth between 1 or more colleagues, id probably just throw a private fork somewhere that we both had write access to

ghaskins
2016-09-20 21:14
but those circumstances should be rare for a FOSS type project

ghaskins
2016-09-20 21:14
ideally anyway

ghaskins
2016-09-20 21:14
have to run, ttyl

yacovm
2016-09-20 21:15
bye

chainsaw
2016-09-21 00:31
@ghaskins is BMX IBM Blockchain still 0.5? Prior to the upgrade to 0.4.2 my learn-chaincode finished was working but now I keep getting this error: { "jsonrpc": "2.0", "error": { "code": -32003, "message": "Query failure", "data": "Error when querying chaincode: Error:Failed to launch chaincode spec(Error starting container: API error (500): Error: image library/976f2c99-b4d5-47f1-8625-050cc3567aca-vp1-f1846c248dcfa64fbfe7176a85b2fdfaeb3f4bc742d68666ab0715f61d3c10f0fea5bb3611235f1697a71e10d8667d3f46cd99cacf42f3ba7084add1a63f8fc4 not found\n)" }, "id": 0 }

chainsaw
2016-09-21 00:32
any idea why I'm getting this?

chainsaw
2016-09-21 00:33
Here's the result to the successful deploy: { "jsonrpc": "2.0", "result": { "status": "OK", "message": "f1846c248dcfa64fbfe7176a85b2fdfaeb3f4bc742d68666ab0715f61d3c10f0fea5bb3611235f1697a71e10d8667d3f46cd99cacf42f3ba7084add1a63f8fc4" }, "id": 0 }

chainsaw
2016-09-21 00:35
Is there a slack channel for Bluemix IBM Blockchain?

ghaskins
2016-09-21 01:02
@garisingh: ^^^

hurf
2016-09-21 09:17
has joined #fabric-dev

srirama_sharma
2016-09-21 11:44
has joined #fabric-dev

hgabor
2016-09-21 12:10

ghaskins
2016-09-21 13:26
@bsmita what happens when you run “java -server” on your power system?

bsmita
2016-09-21 13:27
@ghaskins I get the usage

ghaskins
2016-09-21 13:27
ok, thats a good sign

bsmita
2016-09-21 13:27
yes, also I tried IBM Java, java -client also gives usage

ghaskins
2016-09-21 13:27
it seems I can trivially opt between -server and -client without changing code

ghaskins
2016-09-21 13:27
ok, i remembered the IBM java problem

ghaskins
2016-09-21 13:28
it was related to the bootclasspath

ghaskins
2016-09-21 13:28
did you try chaintool there perhaps?

ghaskins
2016-09-21 13:28
im curious if bootclasspath is still a problem

bsmita
2016-09-21 13:29
Changing the path and run chaintool?

ghaskins
2016-09-21 13:29
yes, execute “chaintool” on the power system where “java” resolves to IBM java

srirama_sharma
2016-09-21 13:30
@ghaskins , even for “java -server" we see that java usage is shown..

srirama_sharma
2016-09-21 13:30
``root@p006vm40:~/git/src/github.com/hyperledger/fabric# java -server Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -d32 use a 32-bit data model if available -d64 use a 64-bit data model if available -server to select the "server" VM -zero to select the "zero" VM -dcevm to select the "dcevm" VM The default VM is server, because you are running on a server-class machine.```

ghaskins
2016-09-21 13:30
yes, that is ok…it seems “java -client” blows up on ppc

ghaskins
2016-09-21 13:30
no usage, you get error

srirama_sharma
2016-09-21 13:30
yes

ghaskins
2016-09-21 13:30
whereas every other platform, -client or -server just return usage

bsmita
2016-09-21 13:30
```$>./chaintool Error: Could not find or load main class chaintool.core ```

bsmita
2016-09-21 13:31
with IBM Java in the path first

ghaskins
2016-09-21 13:31
yes, ok, that is the bootclasspath problem

ghaskins
2016-09-21 13:31
it seems there is some -Xbootclasspath option that open/oracle java supports that IBM java doesnt

ghaskins
2016-09-21 13:31
i digress

bsmita
2016-09-21 13:31
ok

ghaskins
2016-09-21 13:31
let me see if I can get around the -client problem

bsmita
2016-09-21 13:31
Thank you

srirama_sharma
2016-09-21 13:32
probably a naive questin.. where is the -client option being set ? and why is it required ?

bsmita
2016-09-21 13:32
I was looking at chaintool source code last night, and could not find that in the code, is it default?

ghaskins
2016-09-21 13:34
I am using “lein-bin” (see project.clj in root)

ghaskins
2016-09-21 13:34
this is a plugin which generates the preamble

srirama_sharma
2016-09-21 13:34
Oh. ok.

ghaskins
2016-09-21 13:34

ghaskins
2016-09-21 13:37
cool, i was able to get it adjusted


ghaskins
2016-09-21 13:37
@bsmita do you want me to send you the binary or a patch to chaintool which you can build locally?

ghaskins
2016-09-21 13:38
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F2E6QU87K/-.sh and commented: Heres the patch

bsmita
2016-09-21 13:38
thanks, let me try this

ghaskins
2016-09-21 13:38
just apply this, run “make clean all” and then the new binary is ./target/chaintool

bsmita
2016-09-21 13:39
ok

ghaskins
2016-09-21 13:40
have to step out for an hour

ghaskins
2016-09-21 13:41
ttyl

bsmita
2016-09-21 13:41
sure

srirama_sharma
2016-09-21 13:55
@ghaskins @bsmita, after applying the patch to project.clj , was able to build the chaintool and the newly built binary doesn’t give any error. I see ```root@p006vm40:~/test/fabric-chaintool# ./target/chaintool chaintool version: v0.9.1-SNAPSHOT Usage: chaintool [general-options] action [action-options] General Options: -v, --version Print the version and exit -h, --help Actions: build -> Build the chaincode project buildcar -> Build the chaincode project from a CAR file clean -> Clean the chaincode project package -> Package the chaincode into a CAR file for deployment unpack -> Unpackage a CAR file ls -> List the contents of a CAR file proto -> Compiles a CCI file to a .proto inspect -> Retrieves metadata from a running instance (run "chaintool <action> -h" for action specific help) root@p006vm40:~/test/fabric-chaintool# ```

srirama_sharma
2016-09-21 13:55
Testing with the new chaintool to run unit-tests

ghaskins
2016-09-21 14:01
Ok cool. I'll queue the patch for the next cycle

srirama_sharma
2016-09-21 14:20
ok. Thanks!

srirama_sharma
2016-09-21 14:32
would we need to do changes to fabric/Makefile to pick these changes ? I see it currently is picking up 0.9.0 version```curl -L https://github.com/hyperledger/fabric-chaintool/releases/download/$(CHAINTOOL_RELEASE)/chaintool > $@```

ghaskins
2016-09-21 14:56
back

ghaskins
2016-09-21 14:56
yes, first I need to get a patch into chaintool approved and cut a new release (v0.9.1 most likely)

ghaskins
2016-09-21 14:56
and then I need to update fabric to reference it

ghaskins
2016-09-21 14:57
what branch are you targeting for the ppcle support?

ghaskins
2016-09-21 14:57
e.g. v0.6, master, convergence?

bsmita
2016-09-21 14:57
0.6

ghaskins
2016-09-21 14:57
ok, ill push a patch for the new chaintool there once its ready

ghaskins
2016-09-21 14:58
ill need to check a few things, but my guess is this is a fairly low-risk change as IIUC the -server/-client options are no-ops on 64 bit JVM

bsmita
2016-09-21 14:58
ok..thanks!

ghaskins
2016-09-21 16:09

muralisr
2016-09-21 18:00
@ghaskins just merged https://github.com/hyperledger/fabric-chaintool/pull/29 for the above. (thanks!)

srirama_sharma
2016-09-21 18:27
Hi @ghaskins @muralisr, thanks for getting this quickly integrated into fabric-chaintool. Is there a CI that builds and releases the new 0.9.2 released chaintool binary ?

srirama_sharma
2016-09-21 18:27
so that we can pull it up in fabric/Makefile.

ghaskins
2016-09-21 18:54
I need to do it manually. Will do shortly

ghaskins
2016-09-21 19:49

hhadass
2016-09-21 21:09
has joined #fabric-dev

akind
2016-09-22 10:41
has joined #fabric-dev

ghaskins
2016-09-22 12:52
@superdcc ping

superdcc
2016-09-22 12:52
has joined #fabric-dev

superdcc
2016-09-22 12:53
thank you~

ghaskins
2016-09-22 12:53
are you trying to build from within the vagrant devenv?

superdcc
2016-09-22 12:53
Nope

superdcc
2016-09-22 12:53
direct in the mac

ghaskins
2016-09-22 12:54
ok, so you need to get rocksdb installed then, and have your CGO environment set properly

superdcc
2016-09-22 12:54
I just want to build the fabirc and use docker

superdcc
2016-09-22 12:54
OKOK

ghaskins
2016-09-22 12:54
you can get hints on what is needed by following what the devenv does

superdcc
2016-09-22 12:55
I just start the fabric !!thank you so much~ what do you think the different about fabric and ethereum? @ghaskins


subax
2016-09-22 13:12
has joined #fabric-dev

ashutoshkumar
2016-09-22 13:37
has joined #fabric-dev

shimron
2016-09-22 15:22
has joined #fabric-dev

chainsaw
2016-09-22 16:37
I also posted this issue on IBM-Blockchain/ibm-blockchain-issues. I'm posting it here for any developers that are or were using IBM Blockchain on BMX for focusing on chaincode development: BMX IBM Blockchain is BROKE for developers who want to deploy their own or demo code from github as IBM documentation describes. The Demo Chaincode Example02 works only from the UI. You cannot deploy it from github. The UI is confusing, because the link to the source code being deployed goes to v0.6 code (shim.ChaincodeStubInterface). If you copy the source code to your own github repo and try to deploy it you get an error complaining about the shim.ChaincodeStubInterface (v0.6 code). If you change the code to v0.5 (shim.ChaincodeStub), it indicates a successful deploy, returning a chaincode ID. But upon examination of the network tab it is clear it did not deploy correctly, it never appears and cannot be found as indicated by a query that returns an error message hinting this. So, clearly something is BROKE in IBM Blockchain on BMX. Again, you can only deploy and operate the Demo Chaincode. You cannot deploy your own code from github, even though it is a perfect copy of the chaincode IBM indicates is being deployed. Another point of confusion is the code level deployed and supported on IBM Blockchain. Is it Fabric v0.5 (shim.ChaincodeStub) or Fabric v0.6 (shim.ChaincodeStubInterface)? Because only code compiled to v0.5 (shim.ChaincodeStub) is consumed without an error indication while code compiled to v0.6 is consumed, but returns an ERROR indicating it does not like the v0.6 code (shim.ChaincodeStubInterface). I highly suggest IBM NOT rely on canned tests baked into the UI--Demo Chaincode. Instead rely on what a developer does: compile chaincode, push it to your github repo, and deploy it using the URL to your github repo. The inability of developers to deploy their own code makes BMX IBM Blockchain at this time USELESS to developers and only a very simple sales demo!

tcnthomas
2016-09-22 18:02
has joined #fabric-dev

tcnthomas
2016-09-22 18:16
hmm. I don’t know about the example02. But I can get the car lease demo (which is more then a simple sales demo) working on bluemix and change all code I want. When I want to run it locally with a local hyperledger then yes I either have to change shim.ChaincodeStub or use the v0.5 ledger locally. To get the car lease demo working I just forked it to my github. Then after downloading it to the Mac I changed the readme.md so the deploy button would use my github repo. Next on the Mac I changed car-lease-demo/Server_Side/configurations/configuration.js. In this configuration is a reference to the standard github repo for vehicles.go data so I changed that as well. Then deployed using the deploy button in the readme.md. Next I just change code on the Mac. Commit and sync with github. And push it from the mac locally using CF push. What happens is then all code is deployed from my Mac locally but the chaincode(vehicles.go) is pulled during deployment from github.

smartyalgo
2016-09-22 21:32
has joined #fabric-dev

david.acton
2016-09-22 23:10
Hello Gang. has the Events features been written yet?

ghaskins
2016-09-22 23:26
@david.acton I believe @pmullaney has this almost wrapped up, but not sure

david.acton
2016-09-22 23:27
@ghaskins Thanks. :slightly_smiling_face: I’ll leave trying to consume them for now then

ghaskins
2016-09-22 23:28
to be clear, it might be in a consumable state, im not sure

ghaskins
2016-09-22 23:28
i defer to Pat

ghaskins
2016-09-22 23:29
one of the last PRs I saw go through related to unit tests in the SDK, so that sounds like its fairly close to working if not already

david.acton
2016-09-22 23:29
ah great.. I’ll check out the SDK.


david.acton
2016-09-23 00:13
@ghaskins Events look to be working ok for block and register at least… Thanks for the info!!

ghaskins
2016-09-23 00:13
yw

bgorman
2016-09-23 00:22
@chainsaw are you sure the v0.5 code you had for example02 was correct and compiled properly? was your shim.ChaincodeStub a pointer (*)?

yaoguo
2016-09-23 03:23
Hi, everyone. For query request, I found fabric didn't generate transaction and sent to consensus. Why query don't need consensus?

bgorman
2016-09-23 05:31
@yaoguo queries don't modify anything, so they just read from the current state of the peer

yaoguo
2016-09-23 05:52
@bgorman there's a chance that different VPs return different query results? Or we should suppose all the VPs are trusted.

chainsaw
2016-09-23 05:55
@bgorman yep. I can compile it with v0.5 and v0.6, changing to ChaincodeStub (v0.5) or ChaincodeStubInterface (v0.6). Only v0.5 returns "OK" and id on deploy, while v0.6 complains about ChaincodeStubInterface, so v0.5 must be still running. I can see my init message arg passed in JSON, but the id does not display in the Network tab, unlike the demo which does. So the Network tab shows no chaincode id, and the Blockchain tab shows 2 blocks, genesis and the deploy. Clicking the deploy block shows the time, chaincode id, and the arg I passed in for the init. Now if I try to query it an error is returned as described above. Others are getting the same error and experiencing the same behavior. There is obviously a disconnect as evidenced by UI observation. Here is the error for easy reference: "error": { "code": -32003, "message": "Query failure", "data": "Error when querying chaincode: Error:Failed to launch chaincode spec(Error starting container: API error (500): Error: image library/976f2c99-b4d5-47f1-8625-050cc3567aca-vp1-f1846c248dcfa64fbfe7176a85b2fdfaeb3f4bc742d68666ab0715f61d3c10f0fea5bb3611235f1697a71e10d8667d3f46cd99cacf42f3ba7084add1a63f8fc4 not found\n)" },...looks like code (image) is not where it should be...but we know it's out there somewhere or not, maybe the Blockchain tab is only displaying result but not proof.

chainsaw
2016-09-23 06:03
I can definitely see this as a differentiator, and why I always prefer and recommend sysops access. Not being able to get a shell is like sailing in the dark blindfolded. Frustrating because you are forced to twiddle your thumbs and argue your case to move boxes :slightly_smiling_face: I guess this is why I'm building my own AWS Fabric development system so I can tame, train, master, and extend this beast.

bgorman
2016-09-23 07:54
@yaoguo the VP you query could be lagging behind consensus or malicious, leading to different results compared to the other (3+) VPs

yaoguo
2016-09-23 08:02
@bgorman So how should i do to get trusted query result?

bgorman
2016-09-23 08:05
@yaoguo I'm not sure what's the best way, but you could query multiple VPs :slightly_smiling_face:

yaoguo
2016-09-23 08:39
@bgorman I'm confused about invoke and query interface. Success response of invoke only means Tx was submitted. Query gets unreliable result. In practice, I'd like a interface to get reliable response which can prove my invoke request was executed successfully, and the query interface should return reliable result.

bgorman
2016-09-23 09:09
What interface are you using @yaoguo? REST and CLI only submit with no response, I think the SDK lets you get a response though (disclaimer: I'm not too familiar with the the sdk)

yacovm
2016-09-23 09:09
wasn't there some kind of event channel?

bgorman
2016-09-23 09:10
Yeah there's events... maybe that's how?

yacovm
2016-09-23 09:10
never used them

yaoguo
2016-09-23 09:22
I'm using CLI. i'm not familiar with sdk too. Event will show invoke result but it's not a user-friendly method. I need listen to event channel and find corresponding event.

roger3cev
2016-09-23 09:27
has joined #fabric-dev

cbf
2016-09-23 12:43
we are aware of the build issue on convergence branch - looks like we may have issues with the ubuntu mirror

ghaskins
2016-09-23 14:12
ill see if I can cherry pick the new v0.1.0 baseimage stuff to convergence

ghaskins
2016-09-23 14:13
the ubuntu repos seem to be a nightmare lately

ghaskins
2016-09-23 14:46
@cbf the convergence problem might be even easier than ^^^^


ghaskins
2016-09-23 14:46
this was reverted in master, but never synced down

ghaskins
2016-09-23 14:47
ill submit a revert and see if that gets the CI pipeline back on track


cbf
2016-09-23 15:14
thx!

hyperpiper
2016-09-23 23:15
Does anyone know how I can resolve this problem?

hyperpiper
2016-09-23 23:16
@hyperpiper uploaded a file: https://hyperledgerproject.slack.com/files/hyperpiper/F2FEA0P1N/screen_shot_2016-09-23_at_5.41.34_pm.png and commented: The error I get when I try to build the chaincode

hart.montgomery
2016-09-24 00:19
has joined #fabric-dev

garisingh
2016-09-24 10:39
@chainsaw, I am not usually one to be "defensive" about things or seem like I am attacking people in the community, but to be direct here I don;t really appreciate these kinds of comments. Totally understand that you posted to the issues which is the right thing to do and I can understand if you wanted to say that we were being unresponsive. But if you have taken a step back, perhaps you could have come up with some constructive comments and improvements for both the BMX Blockchain service as well as the fabric.

garisingh
2016-09-24 10:47
the current struggle we have with the BMX service is that fact that the interface in master / v0.6 changed from what it was in the 0.5 release. We had no way of anticipating this and did not originally want to be stuck "vending" the entire fabric with all of the samples. Further, the v0.5 branch was removed from public access as well - making things even harder. And a few facts: 1) You can deploy your own chaincode to BMX - you simply need to implement the v0.5 shim interface. You don't even need to vendor the fabric to do this because we actually have the fabric in our GOPATH when we compile and deploy the chaincode within BMX. Yes - I realize this makes it impossible to compile locally and we'll fix that by documenting what to do 2) We have a fairly complex setup network wise for BMX and unfortunately some of our internal routing got messed up and resulted in fairly massive delays in deploying chaincode on some of our backend nodes. We are working to fix that I guess my real point is that rather than criticizing, perhaps asking questions about why we did what we did, what the cause of the errors is / was and constructive help in terms of versioning, etc would have been a better approach. Go has no real concept of versions unless you do it artificially. You can find dialog about versioning for fabric interface moving forward in other channels. Oh - and incidentally - for the record I actually do agree with you that we should not embed deployment of the samples in the dashboard. The idea was OK - make it easy for someone who just wants to check things out to get something running, but its problematic in that it does not force us to work on the overall consumability of developing and deploying chaincode

tcnthomas
2016-09-24 11:43
@garisingh Thanks for your explanation

chainsaw
2016-09-25 02:12
@garisingh thank you for the confirmation, sorry for the perceived harshness; I figured there was confusion within BMX and it is ok because it is beta and under development; it is my fault for being too aggressive this early and expecting too much, sorry. FYI, deploying from github still is not working. Response says Ok and returns an ID but the ID never shows up in the Network tab and queries return not found error. I'll demo my IBM clients on our own network until BMX is fixed. NP. :slightly_smiling_face:

garisingh
2016-09-25 08:24
@chainsaw - thanks - no worries.

pushpalatha
2016-09-26 06:40
Hi All, Is there a way we get the information of which node initiated a particular transaction?

cbf
2016-09-26 14:30
actually, there isn’t the tCerts are designed so that you cannot know - only that it is an authorized node

kostas
2016-09-26 18:13
Do we use a tool to handle the `vendor` folder, and if so, which one?

kostas
2016-09-26 18:14
I use Glide but I see a `vendor.json` file in there and guess we do `govendor`?

cbf
2016-09-26 19:34
govendor


kostas
2016-09-27 03:44
@cbf: Got it, thanks for that link as well.

g_alexander
2016-09-27 09:19
has joined #fabric-dev

vzhou
2016-09-27 15:37
has joined #fabric-dev

srirama_sharma
2016-09-27 17:05
In case if I have a large file that is part of the transaction, the whitepaper mentions that it needs to be saved on a off-chain storage and a hash of it is stored within the block. The question is who would own that off-chain storage in the network ? How is immutability of it is taken care of ?

wil.pannell
2016-09-27 21:33
has joined #fabric-dev

baohua
2016-09-28 01:49
@srirama_sharma in this case, you need other scheme (e.g., distributed storage) to save that file. Actually, blockchain is not designed for file storage.

kostas
2016-09-28 08:30
@cbf, @ghaskins: Do we have a timeframe for when the Vagrant image will be upgraded to Go 1.7?

jonathanlevi
2016-09-28 09:09
Hi @kostas, you may want to watch/follow https://jira.hyperledger.org/browse/FAB-129 (@cbf assigned it to Sprint 2, ending Oct 6) which depends on https://jira.hyperledger.org/browse/FAB-289 (already In Progress).

kostas
2016-09-28 09:10
@jonathanlevi: Neat, thanks.

baohua
2016-09-28 09:11
@kostas i’ve already tested on 1.7, seems works.

kostas
2016-09-28 09:13
Roger. Most of my tests for the Kafka orderer use the `t.Run()` sub-test functionality so the sooner we upgrade to 1.7 the better.

jonathanlevi
2016-09-28 09:17
I personally, really wanna to see the native `Z` working. I don’t really need it, but mainly out of curiosity… :wink:

jonathanlevi
2016-09-28 09:17
(speaking of Go 1.7)

cbf
2016-09-28 11:14
It's on the list... probably should consider whether 16.04 or 1.7 is more valuable...

ghaskins
2016-09-28 12:14
@kostas @cbf my plan was to get the new baseimage pipeline stable, and then start one by one upgrading the stuff that is crufty

ghaskins
2016-09-28 12:15
my thought is 1.7 should go in first, only for the reason that 16.04 ships with go1.6 and it seemed silly to leave the manual compilation of 1.6 on top of 16.04

cbf
2016-09-28 12:16
makes sense

ghaskins
2016-09-28 12:16
so, upgrade to manual compilation of go1.7, then 16.04, maybe look at rocks and npm next

ghaskins
2016-09-28 12:16
my guess is we can just go with 16.04 npm

ghaskins
2016-09-28 12:16
its probably 6.x

ghaskins
2016-09-28 12:17
i think everything else comes from the platform, so unless there is a new exception to override, everything else will come from the 16.04 update

cbf
2016-09-28 12:17
@garisingh what do you think?

ghaskins
2016-09-28 12:18
i guess it would be good to find out of we were intentionally holding things back to npm 0.12 (or whatever ancient one we are running now)

garisingh
2016-09-28 12:19
@jzhang and I discussed that we should go with NodeJS 6.x for the v1.0.0 SDK

cbf
2016-09-28 12:19
the npm is historic anachronism I think

cbf
2016-09-28 12:19
totally agree

garisingh
2016-09-28 12:20
I am also a big believer in using nvm to manage node versions

ghaskins
2016-09-28 12:23
@garisingh roger, I will not fret if 16.04 upgrades us to 6.x or whatever, and then we can evaluate if that is new _enough_

garisingh
2016-09-28 12:44
sounds good

srirama_sharma
2016-09-28 13:33
@baohua Thanks for clarifying.. In that case, who (among the blockchain participants) would be owning that distributed storage ? and How is the sanity of such file (or trail of any modification done) maintained ?

baohua
2016-09-28 13:35
can u help clarify the original scenario u are targeting to?

vzhou
2016-09-28 14:43
Hi, how do the peers know where to look for the membersrvc process? Do I just need to run membersrvc on the same machine as every peer?

tuand
2016-09-28 14:53
@vzhou , defined in core.yaml ... search for `pki:`

vzhou
2016-09-28 14:54
got it, thanks!

kostas
2016-09-29 03:08
So, it seems that `govendor add http://github.com/x/y` will just add this package to the `vendor` folder, whereas `govendor fetch http://github.com/x/y` will vendor `x/y` as well as its dependencies.

kostas
2016-09-29 03:08
I assume we want the latter.

kostas
2016-09-29 03:09
_Iff_ that is the case, the "Adding or updating Go packages" section in the documentation should be updated. The only relevant command to a developper is the `govendor fetch` one.

sheehan
2016-09-29 03:34
I wrote that section before the `fetch` command existed in govendor, so yes, it should likely be updated. I'll see if I can get to that soon

baohua
2016-09-29 07:25
do we have any plan to support chaincode upgrade? One customer wants to upgrade their chaincode with accessing to old data in runtime.

ghaskins
2016-09-29 11:46
@baohua @muralisr is working on chaincode lifecycle (deploy, upgrade, terminate)

yacovm
2016-09-29 11:53
Hey, anyone here familiar with the fabric security infrastructure and can help me with something?

garisingh
2016-09-29 12:35
@yacovm - what are you trying to do? I feel like anything security related you add to the gossip work is going to be throwaway. Why not just continue to noop security functions until we get the libraries in shape?

yacovm
2016-09-29 12:36
hmm, actually - I have a question but it's *not* for the gossip but rather the fabric itself

yacovm
2016-09-29 12:37
and why would it be throwaway? I'm planning to use essentially the same security API that the crypto peer has. it does work, doesn't it?

garisingh
2016-09-29 12:37
it needs to be refactored into modular libraries - they are working on a pluggable layer as well

garisingh
2016-09-29 12:38
but I can try to answer your question :wink:

yacovm
2016-09-29 12:39
yeah, but you'll still have a `Sign([]byte)` and a `Verify(vkID, signature, message []byte) ` right? because that's the baseline asymmetric cryptography capability brings

yacovm
2016-09-29 12:39
I really don't care about refactoring and which code resides where...

baohua
2016-09-29 12:48
thanks ghaskins!

grbulat
2016-09-29 13:12
has joined #fabric-dev

ghaskins
2016-09-29 19:14

ghaskins
2016-09-29 19:15
note specifically that I consolidated x86 and s390x into one conditional since s390x is now supported in a variety of projects (e.g. go and npm both support it now)

ghaskins
2016-09-29 19:15
let me know if you or the rest of the Z team see a problem with that

vpaprots
2016-09-29 20:37
@ghaskins thanks. will pull a new copy.. been trying to fix the z build for few days now! whomever picked gradle as a build tool... i would have some words.

vpaprots
2016-09-29 20:40
since we are on the topic... how much opposition would there be to upgrading some of the protobuf packages.. i.e. - classpath 'com.google.protobuf:protobuf-gradle-plugin:0.7.6' + classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.0' and - artifact = 'io.grpc:protoc-gen-grpc-java:0.13.2' + artifact = 'io.grpc:protoc-gen-grpc-java:1.0.0'

vpaprots
2016-09-29 20:40
protobuf-gradle-plugin:0.8.0 in particular has some platform fixes I need

kostas
2016-09-29 20:46
```vagrant@hyperledger-devenv:v0.0.10-2419d48:/opt/gopath/src/github.com/hyperledger/fabric$ touch orderer/config/config_test.go vagrant@hyperledger-devenv:v0.0.10-2419d48:/opt/gopath/src/github.com/hyperledger/fabric$ make peer make: Warning: File `orderer/kafka/config_test.go' has modification time 1.7e+02 s in the future```

kostas
2016-09-29 20:47
This can't be right, can it?


yacovm
2016-09-29 20:57
is it *ok* for me to submit a PR that patches the package in the vendor folder? I think the license allows it


ghaskins
2016-09-29 21:12
@kostas I think those problems are related to the fact that /opt/gopath/src/github.com/hyperledger/fabric is a filesystem punched through to your host

ghaskins
2016-09-29 21:13
i suspect you are editing the file on your host?

kostas
2016-09-29 21:13
But shouldn't `touch` bring it in sync with the VM's clock?

kostas
2016-09-29 21:13
(Yes.)

ghaskins
2016-09-29 21:13
maybe…it might be that your host clock is far enough out of sync that touch wont move it backwards

ghaskins
2016-09-29 21:13
not sure

ghaskins
2016-09-29 21:14
generally speaking, i ignore those warnings

kostas
2016-09-29 21:14
Gotcha, will do the same then. Thank you.

chetsky
2016-09-30 01:58
@kostas I must demur on ignoring these time warnings. It's too trivial to fix .... tojust ignore. typically, before I start working in a VM, either I ntpdate, or I rdate to another server tn get the VM's time up-to-date. If your VM is skewing enough that it matters, you might write a cron job to run the cmd every 10min. A clock skewing upr ethan that .... well, something's wrong.

chetsky
2016-09-30 01:59
I've run decent-sized networks of machines without bothering to setup ntpd properly, just by putting ntpdate into cron jobs. "just enough is good enough"

chetsky
2016-09-30 01:59
Also, if you're going to use automated tools, those tools use timestamps for many things. Not trusting the time, means you have to do make clean more often, and that costs time.

chetsky
2016-09-30 02:00
when the solution is so cheeeeep .....

chetsky
2016-09-30 02:01
N.B. for ntpdate, you gotta find an NTP server. that might be not-so-easy, though it shouldn't be.

chetsky
2016-09-30 02:01
for rdate, you just gotta hit a machine whose inetd/xinetd has enabled the "date" server. That machine can be the host machine on which the VM guest runs

chetsky
2016-09-30 02:01
it's really not hard

kostas
2016-09-30 02:33
@chetsky `sudo ntpdate http://pool.ntp.org` did the trick - thanks!

shannon_wie
2016-09-30 05:55
has joined #fabric-dev

lenh
2016-09-30 13:07
has joined #fabric-dev

fredericdgrv
2016-09-30 13:58
has joined #fabric-dev

thefringe
2016-09-30 14:20
has joined #fabric-dev

thefringe
2016-09-30 14:23
Hi guys, is this error familiar? Error building images: Error: image hyperledger/fabric-ccenv:x86_64- not found

ghaskins
2016-09-30 14:39
@thefringe no, it looks like the tag is not fully formed

ghaskins
2016-09-30 14:39
can you give me any details of your environment, what you are trying to do, etc?

ghaskins
2016-09-30 14:40
(whats missing is a version: it should look like “..fabric-ccenv:x86_64-0.7.0-snapshot” or something like that

thefringe
2016-09-30 14:42
I'm running ubuntu 16.04.1. I'm using this docker-compose yml: https://github.com/yeasy/docker-compose-files/blob/master/hyperledger/noops/docker-compose.yml

thefringe
2016-09-30 14:42
And i'm just trying to deploy some homemade chaincode basically nothing fancy

thefringe
2016-09-30 14:44
oh and @garisingh This is with the nodesdk and rest api

superdcc
2016-10-01 08:34
Hello Guys~~ How can i figure out the problem? Error getting chaincode package bytes: Error getting code Getting chaincode took too long

superdcc
2016-10-01 08:35
I know the default is :deploytimeout: 30000

superdcc
2016-10-01 08:35
but my chaincode'go file is big i think ...

superdcc
2016-10-01 08:59
after change the time num, i compile again, it work , thank you^^

elisabetta
2016-10-03 09:50
Morning

elisabetta
2016-10-03 09:51
s390x build seems broken: root@Peer-70:/opt/hyperledger/git/src/github.com/hyperledger/fabric/build/image/src# docker build -t hyperledger/fabric-src . Sending build context to Docker daemon 11.54 MB Step 1 : FROM hyperledger/fabric-baseimage:s390x-0.1.0 Pulling repository http://docker.io/hyperledger/fabric-baseimage Tag s390x-0.1.0 not found in repository http://docker.io/hyperledger/fabric-baseimage

ghaskins
2016-10-03 13:40
@elisabetta s390x support hasnt been added to the image pipeline, you’ll need to use the v0.6-preview branch for now

ghaskins
2016-10-03 13:41
that still works with the old mechanism

lenh
2016-10-03 14:16
@ghaskins - I'm calling the Fabric (running in a Vagrant VM) from another VM running the HFC NodeSDK and am running through the enroll, deploy, invoke, query cycle but am getting this error: ```Failed to query chaincode: request={"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","fcn":"query","args":["a"]}, error=%k EventTransactionError { error: { status: 'FAILURE', msg: <Buffer 45 72 72 6f 72 3a 46 61 69 6c 65 64 20 74 6f 20 6c 61 75 6e 63 68 20 63 68 61 69 6e 63 6f 64 65 20 73 70 65 63 28 43 6f 75 6c 64 20 6e 6f 74 20 67 65 ... > }, msg: 'Error:Failed to launch chaincode spec(Could not get deployment transaction for 56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 - LedgerError - ResourceNotFound: ledger: resource not found)' }``` On the HFC NodeSDK VM I have the chaincode (example02) and it builds without fault. I'm logging to the console and get this...

lenh
2016-10-03 14:17
```Enrolled JohnDoe successfully deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"} invoke chaincode ... invoke submitted successfully; results={"uuid":"a92527d5-5c18-48d5-81a7-597ac0b25f3b"} invoke completed successfully; results={"result":"Tx a92527d5-5c18-48d5-81a7-597ac0b25f3b complete"} Waiting for chain to sync... querying chaincode ... Failed to query chaincode: request={"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","fcn":"query","args":["a"]}, error=%k EventTransactionError { error: { status: 'FAILURE', msg: <Buffer 45 72 72 6f 72 3a 46 61 69 6c 65 64 20 74 6f 20 6c 61 75 6e 63 68 20 63 68 61 69 6e 63 6f 64 65 20 73 70 65 63 28 43 6f 75 6c 64 20 6e 6f 74 20 67 65 ... > }, msg: 'Error:Failed to launch chaincode spec(Could not get deployment transaction for 56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 - LedgerError - ResourceNotFound: ledger: resource not found)' }```

lenh
2016-10-03 14:18
So it looks to me like the enroll, invoke, etc worked but then get that LedgerError - also FYI - I'm waiting 2.5 mins before calling the query...

lenh
2016-10-03 14:19
I have however noticed this output on the Peer console: ```14:06:22.860 [rest] StartOpenchainRESTServer -> INFO 013 Initializing the REST service on 0.0.0.0:7050, TLS is disabled. 2016/10/03 14:06:37 grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: write tcp 10.10.10.200:7051->10.10.10.150:33133: write: broken pipe" 14:06:48.873 [dockercontroller] deployImage -> ERRO 014 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 14:06:48.874 [dockercontroller] deployImage -> ERRO 015 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 14:06:58.526 [dockercontroller] deployImage -> ERRO 016 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 14:06:58.526 [dockercontroller] deployImage -> ERRO 017 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 14:06:58.526 [chaincode] Launch -> ERRO 018 launchAndWaitForRegister failed Error starting container: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 2016/10/03 14:08:37 transport: http2Server.HandleStreams failed to receive the preface from client: EOF 2016/10/03 14:11:17 transport: http2Server.HandleStreams failed to receive the preface from client: EOF```

lenh
2016-10-03 14:19
So now I'm a bit lost - did the deploy work?

elisabetta
2016-10-03 14:22
@ghaskins: thanks Greg.

ghaskins
2016-10-03 16:24
@lenh looking now

ghaskins
2016-10-03 16:26
@lenh if I had to guess, id say the deploy and subsequent invoke failed, but because they are “open loop” right now, your client couldnt tell

ghaskins
2016-10-03 16:26
and then it became apparent in the query, which is synchronous

ghaskins
2016-10-03 16:27
so, bit of background: historically the event-path has been missing in the SDK so things like invoke are generally asynchronous

lenh
2016-10-03 16:27
ok - how come though it responds with: ```deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"} invoke chaincode ... invoke submitted successfully; results={"uuid":"a92527d5-5c18-48d5-81a7-597ac0b25f3b"} invoke completed successfully; results={"result":"Tx a92527d5-5c18-48d5-81a7-597ac0b25f3b complete"}```

ghaskins
2016-10-03 16:27
hmm, you do have a point there

ghaskins
2016-10-03 16:27
let me re-look with that in consideration

ghaskins
2016-10-03 16:28
that is coming from the client?

lenh
2016-10-03 16:28
yes

lenh
2016-10-03 16:28
via the calls to SDK methods

ghaskins
2016-10-03 16:28
right ok…im spitballing a bit here, but I think its wrong

ghaskins
2016-10-03 16:29
part of the problem is that, like I mentioned, the event feedback mechanism has been missing…so the SDK had to synthesize “success"

ghaskins
2016-10-03 16:29
for instance, the SDK just waits 5 seconds for an invoke and then synthesizes that it completed

ghaskins
2016-10-03 16:30
there is ongoing work by @pmullaney to close the loop on this by providing event substrate that the SDK will hook into

ghaskins
2016-10-03 16:30
what I suspect is happening is you are being tricked into thinking it worked when really your backend is not launching the chaincode properly

ghaskins
2016-10-03 16:30
(to be clear, I am speculating)

ghaskins
2016-10-03 16:31
but based on the peer errors, I think the deploy failed

ghaskins
2016-10-03 16:31
and thus all subsquent operations fail as well

lenh
2016-10-03 16:31
yeah `deployImage -> ERRO 014 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage` would seem to point to that

ghaskins
2016-10-03 16:31
right

ghaskins
2016-10-03 16:31
i have to put my kid on the bus, but we should be able to straighten this out when I get back in 10m

lenh
2016-10-03 16:31
no worries

ghaskins
2016-10-03 16:41
back

ghaskins
2016-10-03 16:41
so, as to the issue with baseimage: i think I know what might be wrong

ghaskins
2016-10-03 16:42
first background: we dont (yet) support running the peer from anything except locally built sources

ghaskins
2016-10-03 16:42
e,g,: the only way it will work “turnkey” is if you do something like “make peer && peer node start” from an environment such as the vagrant vm

ghaskins
2016-10-03 16:43
my guess is you are running the peer in some other scenario where a “make peer” hasnt been run?

ghaskins
2016-10-03 16:43
(side note: we will be fixing this in the coming weeks)

ghaskins
2016-10-03 16:43
but for now, that is a limitation

ghaskins
2016-10-03 16:44
it is of course possible to run it outside of vagrant+make-peer, but you have to massage things

ghaskins
2016-10-03 16:44
I believe this is what the bluemix team does, for instance

ghaskins
2016-10-03 16:46
so my first question @lenh is: when you say you run the peer in a “Vagrant VM” do you mean you are running it in the fabric devenv?

ghaskins
2016-10-03 16:46
or is it a custom vagrant setup?

lenh
2016-10-03 16:46
Yes

ghaskins
2016-10-03 16:46
second question: how are you running it?

ghaskins
2016-10-03 16:47
yes = devenv vagrant, or yes == custom vagrant?

lenh
2016-10-03 16:48
As follows: 1. boot HL Fabric VM 2. ssh into 3. rm -rf /var/hyperledger/production 4. clear local keyStore (on other machine /tmp....) 5. membersrvc > membersrvc.log 2>&1& 6. peer node start

ghaskins
2016-10-03 16:48
ok, where did the “peer” binary come from?

ghaskins
2016-10-03 16:48
did you previously do a build?

lenh
2016-10-03 16:48
yes when I 1st provisioned the HL VM

lenh
2016-10-03 16:49
a few days ago

ghaskins
2016-10-03 16:49
from the VM, what do you see if you run “docker images | grep baseimage"

lenh
2016-10-03 16:49
hyperledger/fabric-baseimage x86_64-0.1.0 db53d04b117c 13 days ago 1.39 GB

ghaskins
2016-10-03 16:50
and can you send me the “git rev-parse —short HEAD” output from your fabric.git repo?

ghaskins
2016-10-03 16:51
i suspect you are on master, but an older rev

ghaskins
2016-10-03 16:52
(we got rid of all baseimage:latest references in HEAD, IIUC)

ghaskins
2016-10-03 16:52
so my guess right now is you are on master, but slightly out of date

lenh
2016-10-03 16:54
that git cmd gives me an error...?

lenh
2016-10-03 16:55
i should run that from the /hyperledger/fabric dir on my host os yes?

ghaskins
2016-10-03 16:56
well, its probably not at that path on your host

ghaskins
2016-10-03 16:56
you can run it from the vm at that path though, i think

ghaskins
2016-10-03 16:56
hold on, let me fire one up so I can tell you exactly

ghaskins
2016-10-03 16:56
(actually, shortest answer is: run it from the same path you run “vagrant up"

lenh
2016-10-03 16:57
ok cause vagrant up is from /fabric/devenv but the fabric was cloned into /fabric

ghaskins
2016-10-03 16:58
ok, do it from /fabric or anywhere below that

ghaskins
2016-10-03 16:58
you just need to be in the CWD of the git tree, one way or the other

lenh
2016-10-03 16:59
git rev-parse --short HEAD 1866020

ghaskins
2016-10-03 17:00
hmm, run this

ghaskins
2016-10-03 17:00
git log --oneline

lenh
2016-10-03 17:01
```1866020 Changed docs/nodeSDK/sample-standalone-app.md 131b36c Merge " Java shim build update in DEV mode" 42ca84b FAB-506 broken links fixes and added new targets 79589a5 Java shim build update in DEV mode dd5cef6 Merge "FAB-425 - improve initial experience" f5ea7b5 Merge v0.6 branch 158480c FAB-425 - improve initial experience 4173edd Updating SDK README For NPM Publish ace3143 Updating SDK README For NPM Publish 8d18b21 Node.js SDK -- Upgrading gRPC Version 0fa60ba Node.js SDK -- Upgrading gRPC Version fc09672 Merge "node-SDK: add unit tests for chaincode events" 1392fa1 Merge "node-SDK: add multi-callback registrations" cd0c5dd Node.js SDK -- Lock TypeScript Version to 1.8.10 c7963ea Node.js SDK -- Lock TypeScript Version to 1.8.10 ceefb12 Merge "Animation abstract & landing page for V1 video" e0b9e0e Merge "Do not build the fabric peer during vagrant provision" eba4553 node-SDK: add unit tests for chaincode events 57bbb61 Merge "Busywork updates 9/22/2016" 4d4df36 node-SDK: add multi-callback registrations ce2ef23 Do not build the fabric peer during vagrant provision 02431ee Busywork updates 9/22/2016 3cfaeb5 Merge "Switch to new baseimage-pipeline"```

ghaskins
2016-10-03 17:01
ok, interesting

ghaskins
2016-10-03 17:01
seems like you have the right code

ghaskins
2016-10-03 17:02
how about “git grep baseimage"

ghaskins
2016-10-03 17:02
?

lenh
2016-10-03 17:02
this is what makes me think there's something amiss... ```2016/10/03 16:51:18 grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: write tcp 10.10.10.200:7051->10.10.10.150:33156: write: broken pipe" 16:51:31.636 [dockercontroller] deployImage -> ERRO 014 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 16:51:31.636 [dockercontroller] deployImage -> ERRO 015 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage```

ghaskins
2016-10-03 17:03
well, its the “FROM … baseimage” that is surprising

ghaskins
2016-10-03 17:03
those should have been eradicated at runtime in the version of code you are running

ghaskins
2016-10-03 17:04
(the “latest” tag not found is actually expected

ghaskins
2016-10-03 17:04
but it shouldnt be looking for that image at all

ghaskins
2016-10-03 17:04
the latest code should be doing a "FROM …. fabric-ccenv” so I am trying to figure out where that is originating from

lenh
2016-10-03 17:05
```warning: unable to access '/home/vagrant/.config/git/attributes': Permission denied Makefile:BASEIMAGE_RELEASE=$(shell cat ./.baseimage-release) Makefile: hyperledger/fabric-baseimage:$(BASE_DOCKER_TAG) go install http://github.com/golang/protobuf/protoc-gen-go devenv/Vagrantfile:baseimage_release = File.read '../.baseimage-release' devenv/Vagrantfile: config.vm.box = "hyperledger/fabric-baseimage" devenv/Vagrantfile: config.vm.box_version = ENV['USE_LOCAL_BASEIMAGE'] ? "0": baseimage_release # Vagrant does not support versioning local image devenv/setup.sh:BASEIMAGE_RELEASE=`cat /etc/hyperledger-baseimage-release` examples/chaincode/go/utxo/README.md:Next, modify the `core.yaml` file in the Hyperledger Fabric project to point to the local Docker image that w images/src/Dockerfile.in:FROM hyperledger/fabric-baseimage:_BASE_TAG_ membersrvc/ca/ca_test.yaml: from hyperledger/fabric-baseimage:latest sdk/node/src/hfc.ts: "from hyperledger/fabric-baseimage" + "\n" + ```

ghaskins
2016-10-03 17:05
ok, that looks right

ghaskins
2016-10-03 17:06
and those messages came from the peer?

lenh
2016-10-03 17:06
the only change I have is a pvte IP assigned in Vagrantfile

lenh
2016-10-03 17:06
yes from the Peer

ghaskins
2016-10-03 17:06
private IP should be fine

ghaskins
2016-10-03 17:06
this is very strange

lenh
2016-10-03 17:07
yeah the comms all work - the enroll etc is all good - I see the files / etc being created on both ends /tmp/Key.... on client and /var/hyperledger/production on "server"

ghaskins
2016-10-03 17:07
right

lenh
2016-10-03 17:08
here's the full output from peer: ```vagrant@hyperledger-devenv:v0.1.0-131b36c:/opt/gopath/src/github.com/hyperledger/fabric/build/bin$ peer node start 16:51:02.555 [nodeCmd] serve -> INFO 002 Security enabled status: false 16:51:02.555 [nodeCmd] serve -> INFO 003 Privacy enabled status: false 16:51:02.555 [eventhub_producer] start -> INFO 001 event processor started 16:51:02.585 [chaincode] NewChaincodeSupport -> INFO 004 Chaincode support using peerAddress: 0.0.0.0:7051 16:51:02.586 [sysccapi] RegisterSysCC -> INFO 005 system chaincode (noop,http://github.com/hyperledger/fabric/bddtests/syschaincode/noop) disabled 16:51:02.590 [state] loadConfig -> INFO 006 Loading configurations... 16:51:02.590 [state] loadConfig -> INFO 007 Configurations loaded. stateImplName=[buckettree], stateImplConfigs=map[maxGroupingAtEachLevel:%!s(int=5) bucketCacheSize:%!s(int=100) numBuckets:%!s(int=1000003)], deltaHistorySize=[500] 16:51:02.591 [state] NewState -> INFO 008 Initializing state implementation [buckettree] 16:51:02.591 [buckettree] initConfig -> INFO 009 configs passed during initialization = map[string]interface {}{"numBuckets":1000003, "maxGroupingAtEachLevel":5, "bucketCacheSize":100} 16:51:02.591 [buckettree] initConfig -> INFO 00a Initializing bucket tree state implemetation with configurations &{maxGroupingAtEachLevel:5 lowestLevel:9 levelToNumBucketsMap:map[7:40001 5:1601 8:200001 1:3 0:1 4:321 2:13 6:8001 3:65 9:1000003] hashFunc:0xab1cd0} 16:51:02.592 [buckettree] newBucketCache -> INFO 00b Constructing bucket-cache with max bucket cache size = [100] MBs 16:51:02.592 [buckettree] loadAllBucketNodesFromDB -> INFO 00c Loaded buckets data in cache. Total buckets in DB = [0]. Total cache size:=0 16:51:02.594 [consensus/controller] NewConsenter -> INFO 00d Creating default consensus plugin (noops) 16:51:02.601 [consensus/noops] newNoops -> INFO 00e NOOPS consensus type = *noops.Noops 16:51:02.601 [consensus/noops] newNoops -> INFO 00f NOOPS block size = 500 16:51:02.601 [consensus/noops] newNoops -> INFO 010 NOOPS block wait = 1s 16:51:02.602 [nodeCmd] serve -> INFO 011 Starting peer with ID=name:"jdoe" , network ID=dev, address=0.0.0.0:7051, rootnodes=, validator=true 16:51:02.604 [consensus/statetransfer] blockThread -> INFO 012 Validated blockchain to the genesis block 16:51:02.605 [rest] StartOpenchainRESTServer -> INFO 013 Initializing the REST service on 0.0.0.0:7050, TLS is disabled. 2016/10/03 16:51:18 grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: write tcp 10.10.10.200:7051->10.10.10.150:33156: write: broken pipe" 16:51:31.636 [dockercontroller] deployImage -> ERRO 014 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 16:51:31.636 [dockercontroller] deployImage -> ERRO 015 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 16:51:40.973 [dockercontroller] deployImage -> ERRO 016 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 16:51:40.973 [dockercontroller] deployImage -> ERRO 017 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 16:51:40.973 [chaincode] Launch -> ERRO 018 launchAndWaitForRegister failed Error starting container: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 2016/10/03 16:53:18 transport: http2Server.HandleStreams failed to receive the preface from client: EOF 2016/10/03 16:56:08 transport: http2Server.HandleStreams failed to receive the preface from client: EOF```

ghaskins
2016-10-03 17:08
this is very confusing

ghaskins
2016-10-03 17:09
can you try this from the VM: find $GOPATH -type f | xargs grep baseimage

lenh
2016-10-03 17:09
it's at `2016/10/03 16:51:18` that things start wobbling

ghaskins
2016-10-03 17:09
the only thing I can think of is you have some core.yaml floating around

lenh
2016-10-03 17:09
mmmhhhh

lenh
2016-10-03 17:10
like the one from the car-lease-demo perhaps?

ghaskins
2016-10-03 17:10
the FROM directives are in the .yaml, but I am not sure where the FROM baseimage is coming from as I changed all of those

ghaskins
2016-10-03 17:10
ah, heh, yah probably

ghaskins
2016-10-03 17:10
are you using an override?

lenh
2016-10-03 17:10
let me check something quick

ghaskins
2016-10-03 17:10
sure…whatever yaml you think is in use, grep for “baseimage"

ghaskins
2016-10-03 17:10
thats probably the issue

lenh
2016-10-03 17:12
you know what - just to be 100% sure - let me destroy this box and provision it again quickly so it's 100% on the latest and untouched...

ghaskins
2016-10-03 17:12
that should resolve it

ghaskins
2016-10-03 17:12
(if its a bad yaml problem, i mean)

lenh
2016-10-03 17:13
yeah - I do recall spending a few hours on the weekend trying to get car-lease working but gave up in the end...

lenh
2016-10-03 17:13
so it's better to try a fresh install

lenh
2016-10-03 17:13
and I'll clone from fresh...

ghaskins
2016-10-03 17:13
cool

ghaskins
2016-10-03 17:14
fwiw, the line that I _think_ is impacting us is here: https://github.com/hyperledger/fabric/blob/master/peer/core.yaml#L285

ghaskins
2016-10-03 17:14
that used to be “FROM … baseimage” and was changed recently

ghaskins
2016-10-03 17:14
so if you have an old yaml in play, that could cause the behavior you are seeing

lenh
2016-10-03 17:14
ok well one way to tell for sure is with completely fresh install...

ghaskins
2016-10-03 17:15
yep

lenh
2016-10-03 17:15
I'll let you know outcome - thanks for the assist...

ghaskins
2016-10-03 17:15
np

ghaskins
2016-10-03 17:17

ghaskins
2016-10-03 17:17
thanks for that

lenh
2016-10-03 17:20
yeah :slightly_smiling_face: saw that - no worries...

lenh
2016-10-03 17:20
happy to help where I can

lenh
2016-10-03 20:29
@ghaskins - something is off with the HFC NodeJS SDK: 1. `make node-sdk-unit-tests` - not a single test passes regardless of `net` or `dev`mode... 2. calling the Fabric from a client running the SDK - query fails...

lenh
2016-10-03 20:29
TL;DR Steps taken: 1. Clean pull of repo + `vagrant up` provisioning - OK 2. `make membersrvc` and `make peer` - OK 3. `make unit-test` - OK So up to this point everything working as expected... 4. `make node-sdk-unit-tests` - FAIL (all of them) I then ran the Behave BDD Tests with `make behave`. I was specifically interested in the `query` transactions which all seemed to pass.

ghaskins
2016-10-03 20:30
@lenh I would ping the folks over on #fabric-sdk-node

lenh
2016-10-03 20:30
Here is the output from Behave: ```Failing scenarios: java_shim.feature:121 Java TableExample chaincode single peer 4 features passed, 1 failed, 3 skipped 39 scenarios passed, 1 failed, 9 skipped 549 steps passed, 1 failed, 270 skipped, 0 undefined Took 19m20.454s make: *** [behave] Error 1```

lenh
2016-10-03 20:30
ok

ghaskins
2016-10-03 20:30
i consume the SDK from NPM and don’t get very involved in the building/testing, so I dont have much advice to offer

lenh
2016-10-03 20:31
sure - but even installing with npm result in the same issues when querying the chain...

lenh
2016-10-03 20:32
I'll pop my findings in the SDK channel and hopefully the folks there can figure out what's happening

lenh
2016-10-03 20:32
FYI though - that peer issue didn't go away with the fresh pull...

lenh
2016-10-03 20:33
```20:00:43.587 [rest] StartOpenchainRESTServer -> INFO 014 Initializing the REST service on 0.0.0.0:7050, TLS is disabled. 2016/10/03 20:08:24 grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: write tcp 10.10.10.200:7051->10.10.10.150:33175: write: broken pipe" 20:08:35.615 [dockercontroller] deployImage -> ERRO 015 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 20:08:35.616 [dockercontroller] deployImage -> ERRO 016 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 20:08:44.837 [dockercontroller] deployImage -> ERRO 017 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 20:08:44.837 [dockercontroller] deployImage -> ERRO 018 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage Pulling repository http://docker.io/hyperledger/fabric-baseimage ******************** 20:08:44.837 [chaincode] Launch -> ERRO 019 launchAndWaitForRegister failed Error starting container: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage 2016/10/03 20:10:24 transport: http2Server.HandleStreams failed to receive the preface from client: EOF 2016/10/03 20:13:14 transport: http2Server.HandleStreams failed to receive the preface from client: EOF```

lenh
2016-10-03 20:40
OK - I've dropped my findings in the #fabric-sdk-node channel...

ghaskins
2016-10-03 21:34
@lenh I think I might know what is wrong

ghaskins
2016-10-03 21:34
unfortunately, there is no quick fix other than getting the baseimage installed into your peer

lenh
2016-10-04 07:03
@ghaskins - Ok - I completely deleted both the VM and the baseimage, pulled a fresh copy of the .vbox and did a complete fresh re-install... However, this morning when running `make unit-test` it failed - here is the output:

lenh
2016-10-04 07:04
@lenh uploaded a file: https://hyperledgerproject.slack.com/files/lenh/F2JTCJJNP/make_unit-test_output.txt and commented: make unit-test output

lenh
2016-10-04 07:31
`make behave` output:

lenh
2016-10-04 07:31
```07:27:37 - context.failed = True Failing scenarios: java_shim.feature:121 Java TableExample chaincode single peer 4 features passed, 1 failed, 3 skipped 39 scenarios passed, 1 failed, 9 skipped 549 steps passed, 1 failed, 270 skipped, 0 undefined Took 19m49.205s make: *** [behave] Error 1```

lenh
2016-10-04 07:55
Pulling a fresh copy of the baseimage also did not solve the Peer reporting `07:50:12.971 [dockercontroller] deployImage -> ERRO 015 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage` when deploying chaincode from a client running the NodeSDK...

hgabor
2016-10-04 08:00
@lenh could you check docker images | grep baseimage

hgabor
2016-10-04 08:00
docker images | grep baseimage this

lenh
2016-10-04 08:02
hyperledger/fabric-baseimage x86_64-0.1.0 db53d04b117c 2 weeks ago 1.39 GB

hgabor
2016-10-04 08:02
I also have one tagged with latest

hgabor
2016-10-04 08:02
maybe running make peer-image ?

lenh
2016-10-04 08:03
ok..

hgabor
2016-10-04 08:03
not sure, just a tip

lenh
2016-10-04 08:04
peer is already built - `make peer-image` returns `make: Nothing to be done for peer-image.`

hgabor
2016-10-04 08:05
hm, I will have to look into the docker files

lenh
2016-10-04 08:06
Could not be how docker is being fired?

lenh
2016-10-04 08:07
i.e. the docker images themselves are correct just the invocation is a bit off?

hgabor
2016-10-04 08:07
I think one should have a baseimage tagged with latest

hgabor
2016-10-04 08:08
I have it and it is only 4 days old

lenh
2016-10-04 08:09
are you saying your baseimage is 4 days old when the one it downloaded this morning as a fresh install is 2 weeks old?

lenh
2016-10-04 08:10
as in your virtualbox.box file is 4 days old?

hgabor
2016-10-04 08:10
I think my one was built locally, that's why it is newer

hgabor
2016-10-04 08:11
but not sure

lenh
2016-10-04 08:13
When you say "baseimage" are you referring to the virtualbox.box file which provides the VM OS image (into which the Fabric is then provisioned)? or are you referring to the docker images?

lenh
2016-10-04 08:14
I built membersrvc and peer from scratch this morning so they should both the on the latest published docker images.. I guess...?

lenh
2016-10-04 08:16
I'm no expert but I suspect it has something to do with how docker is firing the container to run the deployed chaincode? This happens when deploying chaincode via the NodeSDK...

lenh
2016-10-04 08:16
Anyway - will leave it to someone with the right pay grade to advise as it's beyond me :slightly_smiling_face:

hgabor
2016-10-04 08:17
I was referring to one of the docker images as you said your Peer reported this: 07:50:12.971 [dockercontroller] deployImage -> ERRO 015 Error building images: Tag latest not found in repository http://docker.io/hyperledger/fabric-baseimage

lenh
2016-10-04 08:18
OK - yes that's what the Peer reports when deploying chaincode via the NodeSDK...

lenh
2016-10-04 08:19
on the client side though it looks like it's completed correctly though... ```deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"}```

hgabor
2016-10-04 08:20
and you can't call it, I guess

lenh
2016-10-04 08:20
I can invoke but can't query...

lenh
2016-10-04 08:20
```invoke submitted successfully; results={"uuid":"96202184-01a2-4455-a102-d365e8024d53"} invoke completed successfully; results={"result":"Tx 96202184-01a2-4455-a102-d365e8024d53 complete"}```

lenh
2016-10-04 08:21
```querying chaincode ... Failed to query chaincode: request={"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","fcn":"query","args":["a"]}, error=%k EventTransactionError { error: { status: 'FAILURE', msg: <Buffer 45 72 72 6f 72 3a 46 61 69 6c 65 64 20 74 6f 20 6c 61 75 6e 63 68 20 63 68 61 69 6e 63 6f 64 65 20 73 70 65 63 28 43 6f 75 6c 64 20 6e 6f 74 20 67 65 ... > }, msg: 'Error:Failed to launch chaincode spec(Could not get deployment transaction for 56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 - LedgerError - ResourceNotFound: ledger: resource not found)' }```

lenh
2016-10-04 08:21
but the folks over in #fabric-sdk-node don't seem surprised that query fails due to some issues they are dealing with that still need merging into the HFC SDK...

lenh
2016-10-04 08:22
so not really worried about the query aspect until they resolve the HFC SDK

hgabor
2016-10-04 08:22
but if invoke works and the query has a bug then doesn't that mean that the chaincode is deployed?

lenh
2016-10-04 08:23
yes - see my msg 12:18 above

hgabor
2016-10-04 08:25
12:18? can't find, please quote

lenh
2016-10-04 08:26
OK - yes that's what the Peer reports when deploying chaincode via the NodeSDK... on the client side though it looks like it's completed correctly though...

lenh
2016-10-04 08:26
```deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"}```

lenh
2016-10-04 08:27
sorry I guess the time is linked to user TZ - my bad

hgabor
2016-10-04 09:02
@lenh just another tip: try make images-clean and then make peer-image

hgabor
2016-10-04 09:05
make images

lenh
2016-10-04 09:07
nope - same result, deploy & invoke seems to work but peer still reporting the `latest tag not found` issue

hgabor
2016-10-04 09:08
still no baseimage:latest?

hgabor
2016-10-04 09:08
for me it built it

hgabor
2016-10-04 09:08
hyperledger/fabric-baseimage latest b0bbba5bc03f About a minute ago 1.386 GB

hgabor
2016-10-04 09:08
I mean I have this now, after clean and build

hgabor
2016-10-04 09:13
I guess you are on master, right?

yaoguo
2016-10-04 09:14
@hgabor hi

hgabor
2016-10-04 09:14
@yaoguo :slightly_smiling_face:

hgabor
2016-10-04 09:17
@lenh are you on master?

lenh
2016-10-04 09:20
how do I check please?

hgabor
2016-10-04 09:21
git log ... and what's the latest commit? :slightly_smiling_face:

lenh
2016-10-04 09:22
commit 5b0a7f0a615e85be01d80b3b5ebd9aa18f49b4ed Merge: bb5b5f8 0b860c3 Author: Jonathan Levi <jonathan@levi.name> Date: Mon Oct 3 17:33:22 2016 +0000 Merge "v1 preview updates"

hgabor
2016-10-04 09:28
oh yeah I checked out and there it works somehow else :slightly_smiling_face:

hgabor
2016-10-04 09:28
baseimage is not deleted


hgabor
2016-10-04 09:28
I guess we needed @ghaskins

hgabor
2016-10-04 09:29
so, that's the repo for baseimage, the only thing I don't know is why you don't have baseimage:latest @lenh

hgabor
2016-10-04 09:29
you could try tagging it but that is a hack :smile:

ghaskins
2016-10-04 12:23
hey guys, just waking up on the east coast

ghaskins
2016-10-04 12:23
I think I know what @lenhs problem is

ghaskins
2016-10-04 12:24
first, note that “baseimage:latest” _used_ to be generated as an artifact of the build, but it isn’t any more

ghaskins
2016-10-04 12:24
second, I think the problem fundamentally is that the SDK creates a tarball that has a FROM directive referencing baseimage:latest that isn’t executed until the tarball hits the peer

hgabor
2016-10-04 12:24
@lenh

hgabor
2016-10-04 12:25
@ghaskins arrived to save the day

hgabor
2016-10-04 12:25
is it better if I remove that from from the sdk code?

ghaskins
2016-10-04 12:25
we need to strategize on the long term solution here, but for the short term we can just manually tag an image on the peer and I think @lenh can get past this

ghaskins
2016-10-04 12:26
@hgabor yeah, ultimately

ghaskins
2016-10-04 12:26
what I have been advocating, but still needs further discussion/agreement, is that the SDK should get out of the docker business

hgabor
2016-10-04 12:26
what from-image to use instead of that?

ghaskins
2016-10-04 12:27
it would be better if the SDK could emit something like a .car file and let the peer and/or chaintool worry about the mapping to a container

hgabor
2016-10-04 12:28
@ghaskins I think this is related to https://gerrit.hyperledger.org/r/#/c/1047/

ghaskins
2016-10-04 12:28
well, if the SDK is going to continue to inject a FROM statement, there isnt a perfect answer…but something like ccenv:0.6.1 would be better

ghaskins
2016-10-04 12:29
theres a ton of problems if we are going to continue to let the SDK create a FROM statement though

hgabor
2016-10-04 12:29
why 0.6.1?

ghaskins
2016-10-04 12:30
well, it should be pinned to something….or we need to synthesize something generic (like we did with baseimage:latest

ghaskins
2016-10-04 12:30
heres an idea

ghaskins
2016-10-04 12:30
1) we take your patch

hgabor
2016-10-04 12:31
taking my stuff is generally a good idea :smile:

ghaskins
2016-10-04 12:31
2) we modify the peer such that it will, as part of start up, do a “docker tag fabric-ccenv:$(ARCH)-$(VERSION) -> :latest"

ghaskins
2016-10-04 12:31
that way, we synthesize the correct tag but we do it at runtime instead of at build time

ghaskins
2016-10-04 12:32
(in the old system, baseimage:latest was synthesized as part of the build)

ghaskins
2016-10-04 12:32
which worked fine, as long as you had run a build

ghaskins
2016-10-04 12:32
that would solve the general problem, at least for now

ghaskins
2016-10-04 12:32
we can worry about cleaning up the deployment payload later

ghaskins
2016-10-04 12:33
thoughts?

hgabor
2016-10-04 12:34
why can't we do it at build time?

ghaskins
2016-10-04 12:34
that only works for people that actually do a build

ghaskins
2016-10-04 12:34
consider lots of people coming on board that only want to run fabirc

ghaskins
2016-10-04 12:35
what I am striving for is that eventually someone can come in cold and say “docker run hyperledger/fabric-peer"

ghaskins
2016-10-04 12:35
in that scenario, there would not be any local build

ghaskins
2016-10-04 12:36
but, if the peer, as part of its startup, where to tag ccenv:latest properly (factoring in the version of the peer, the arch, etc), then the SDK can remain generic

hgabor
2016-10-04 12:36
wait but before running it don't they have to build it?

ghaskins
2016-10-04 12:37
today. that is the only supported way, but that doesnt mean we shouldnt support binary deployments eventually

ghaskins
2016-10-04 12:37
at least IMO

hgabor
2016-10-04 12:38
yeah yeah you are right, but any of the solutions we are talking about can only be temporary, I think

ghaskins
2016-10-04 12:38
yes, imo the SDK creating a Dockerfile/tarball at all should only be temporary…id like to see it gravitate towards using something like a .car file and get out of the packaging business all together

ghaskins
2016-10-04 12:39
e.g. let tooling create chaincode packages, let the SDK(s) deploy the general package, let the peers do the mapping to a container

ghaskins
2016-10-04 12:40
anyway, the summary of the problem is that the SDK is currently assuming too much

hgabor
2016-10-04 12:42
so if it has to be changed to use car why don't we change the current process to tag after each build (as a very temporary solution)?

hgabor
2016-10-04 12:42
and then drive the change :stuck_out_tongue:

ghaskins
2016-10-04 12:42
tag what?

hgabor
2016-10-04 12:43
tag ccenv with latest

ghaskins
2016-10-04 12:43
in dockerhub?

hgabor
2016-10-04 12:44
no, locally, isn't SDK building the image locally?

ghaskins
2016-10-04 12:44
no, and that is in fact part of the story here

ghaskins
2016-10-04 12:44
the SDK is building a tarball with a Dockerfile in it

ghaskins
2016-10-04 12:44
the peer then runs docker-build on it

ghaskins
2016-10-04 12:45
so, the SDK is injecting the FROM baseimage:latest directive because it doesnt know that fabric.git/master got rid of that

ghaskins
2016-10-04 12:45
and then its hitting the peer which is no longer generating baseimage:latest and failing

ghaskins
2016-10-04 12:46
the SDK only prepares the docker build, but it doesnt run it

ghaskins
2016-10-04 12:46
(think of it this way…the Dockerfile+tarball is $X MB, but the resulting container is like 1.4GB

ghaskins
2016-10-04 12:46
we arent sending 1.4GB images around the network :wink:

hgabor
2016-10-04 12:47
yeah now I remember

ghaskins
2016-10-04 12:47
the build happens on the peer (as it should, both from a sheer size perspective, as well as the fact that you cant possibly know the context the peer runs under

ghaskins
2016-10-04 12:47
for instance, one peer could be x86 while another is ppcle

sdiehl
2016-10-04 12:48
has joined #fabric-dev

ghaskins
2016-10-04 12:48
personally, i think this is all suboptimal…the SDK should not be in the Dockerfile business

ghaskins
2016-10-04 12:48
i think it shouldnt even be in the packaging business

ghaskins
2016-10-04 12:49
let it take a generic deployment payload and deploy it

ghaskins
2016-10-04 12:49
let tooling generate optimal deployment payloads

ghaskins
2016-10-04 12:49
brb, kids to school

hgabor
2016-10-04 12:50
okay I see

ghaskins
2016-10-04 12:50
back

ghaskins
2016-10-04 12:51
anyway, i think a temporary solution like the points 1-2 above would be fine

ghaskins
2016-10-04 12:51
if my long term vision is adopted, we can simply deal with it at the chaincodeType level

ghaskins
2016-10-04 12:52
eventually deprecating the GOLANG type that assumes Dockerfile payload

ghaskins
2016-10-04 12:53
@lenh as a workaround for now, on your peer, run “docker tag hyperledger/fabric-ccenv:latest hyperledger/fabric-baseimage:latest"

ghaskins
2016-10-04 12:53
and I think your deployment will start working

hgabor
2016-10-04 12:53
which is easier to implement? which is better?

ghaskins
2016-10-04 12:54
i think the 1-2 point fix is the easiest…IMO the tooling+deployment payload is better

ghaskins
2016-10-04 12:55
so I would be fine with a tactical/strategical tiered fix

ghaskins
2016-10-04 12:57
fwiw, here was a thread discussing the strategical option


ghaskins
2016-10-04 12:57
sorry, this one


hgabor
2016-10-04 12:59
could you review my patch then?

ghaskins
2016-10-04 13:00
i can, but note that the peer side to do the runtime tagging needs to go in first

ghaskins
2016-10-04 13:00
though I suppose we could push this patch in now and it will not make anything worse

ghaskins
2016-10-04 13:00
(because locally built systems do have ccenv:latest

ghaskins
2016-10-04 13:00
actually that is an improvment, since baseimage:latest is no longer valid

ghaskins
2016-10-04 13:01
yes, ok

ghaskins
2016-10-04 13:01
stepping out for a bit

ghaskins
2016-10-04 13:01
bbiab

hgabor
2016-10-04 13:06
first this patch and I will do another for 2)

lenh
2016-10-04 14:00
@ghaskins - tried `docker tag hyperledger/fabric-ccenv:latest hyperledger/fabric-baseimage:latest` - here is the output from the peer node


lenh
2016-10-04 14:01
and here is the client side response to deploying chaincode_example02 via the SDK...

lenh
2016-10-04 14:01
```Hyperldeger REST API provider listening on port 8081 Middleware invoked... Enrolling WebAppAdmin... Enrolled JohnDoe successfully deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"} invoke chaincode ... invoke submitted successfully; results={"uuid":"afe86578-a8e8-4dfd-bb84-70d9c64c3ba8"} invoke completed successfully; results={"result":"Tx afe86578-a8e8-4dfd-bb84-70d9c64c3ba8 complete"} Waiting for chain to sync... querying chaincode ... Failed to query chaincode: request={"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","fcn":"query","args":["a"]}, error=%k EventTransactionError { error: { status: 'FAILURE', msg: <Buffer 45 72 72 6f 72 3a 46 61 69 6c 65 64 20 74 6f 20 6c 61 75 6e 63 68 20 63 68 61 69 6e 63 6f 64 65 20 73 70 65 63 28 43 6f 75 6c 64 20 6e 6f 74 20 67 65 ... > }, msg: 'Error:Failed to launch chaincode spec(Could not get deployment transaction for 56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 - LedgerError - ResourceNotFound: ledger: resource not found)' }```

john.mccloskey
2016-10-04 14:05
has joined #fabric-dev

kostas
2016-10-04 14:15
Quick question: as far as I know the Go 1.7 changeset was merged. When do we see this reflected in the fabric-baseimage and in the Vagrant image?

ghaskins
2016-10-04 15:23
I have to release the baseimage, and then update fabric to reference it

ghaskins
2016-10-04 15:23
neither has happened yet, but ill likely do this in the next 24 hours

ghaskins
2016-10-04 15:24
(for master…v0.6 is not likely to receive the upgrade and convergence _should_ get it but the merge needs to be resolved

ghaskins
2016-10-04 15:24
@kostas ^^^^

ghaskins
2016-10-04 15:25
i will send out a notice to the ML/slack when the upgrade occurs, since people will generally want to rebuild their environments

kostas
2016-10-04 15:25
@ghaskins Thank you. I'll wait for that email before I start posting my changesets.

ghaskins
2016-10-04 15:26
note that my current plan is to rollup all of the patches I recently submitted to baseimage

ghaskins
2016-10-04 15:26
this includes nodejs v6.7.0, go v1.7.1 and ubuntu 16.04

ghaskins
2016-10-04 15:27
do you see that as a problem?

kostas
2016-10-04 15:27
Not at all.

ghaskins
2016-10-04 15:27
ok, cool

ghaskins
2016-10-04 15:28
would you be willing to try the environment after the baseimage release but before the fabric update?

ghaskins
2016-10-04 15:28
its always helpful to have as much testing diversity as possible

ghaskins
2016-10-04 15:29
I can usually rope @cbf and @sheehan in, but I am always looking for other victims^h^h^h^h^h^hvolunteers

kostas
2016-10-04 15:29
Sure thing.

ghaskins
2016-10-04 15:29
ok, ill ping you when its ready

kostas
2016-10-04 15:30
(Do note that I'm not clear on what's the difference between the baseimage release and the fabric update.)

ghaskins
2016-10-04 15:30
well, theres fabric-baseimage.git -> [dockerhub|atlas] -> fabric.git

ghaskins
2016-10-04 15:31
fabric.git simply references the baseimage indirectly by a version tag to atlas/dockerhub

ghaskins
2016-10-04 15:31
so, the first phase is cutting a release in baseimage.git and publishing the images, and the second phase is updating the pointer in fabric.git

ghaskins
2016-10-04 15:32
but I can complete the first phase before phase 2 is merged in, so people can test it

ghaskins
2016-10-04 15:32
thats what we usually do

kostas
2016-10-04 15:32
Ah, alright.

ghaskins
2016-10-04 15:34
fwiw: this is what creates the link


ghaskins
2016-10-04 15:34
so, phase 2 is a CR that updates that value

ratnakar
2016-10-04 15:44
@lenh, I am referring the below error message from your logs ``` Step 4 : RUN go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 ---> Running in 371cd46c924d cp: cannot stat 'src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml': No such file or directory ******************** ``` just wanted to check , whether you have this folder structure `$GOPATH/src/<chaincode>/vendor/github.com/hyperledger/fabric/` where you are running node program ?

lenh
2016-10-04 15:51
@ratnakar - my environment is setup as follows: I have the Fabric running on a Vagrant VM (Fabric) I have another VM running the node SDK (Client) The chaincode is being deployed FROM client TO Fabric

ghaskins
2016-10-04 15:53
@lenh are you building the SDK yourself?

ghaskins
2016-10-04 15:53
or using one from NPM?

lenh
2016-10-04 15:53
But to answer you directly - no I don't have the folder structure you mention...

lenh
2016-10-04 15:53
on the client side I used npm install hfc

ghaskins
2016-10-04 15:54
ok…fwiw, I can give you a one-liner for the SDK that I _think_ will fix your baseimage problem

ghaskins
2016-10-04 15:54
but you would have to build it locally

ghaskins
2016-10-04 15:54
if that is not practical, we can address differently

lenh
2016-10-04 15:55
I can build the SDK but I'm running on windows so for e.g. when I run the node sdk unit test in the VM (because of the Host OS to VM folder mappings) it tried to create the node_modules/node_modules/node_modules dir structure on Windows which is a known issue

ghaskins
2016-10-04 15:56
ah, i see

ghaskins
2016-10-04 15:56
ok

lenh
2016-10-04 15:56
I've overcome this in the past by using creating a symlink though... (so do the node install OUTSIDE of the Vagrant <-> Host OS file mappings)

ghaskins
2016-10-04 15:57
on your peer, can you paste the output of “docker images | grep fabric"

lenh
2016-10-04 15:57
```hyperledger/fabric-membersrvc latest 41c3feac8651 6 hours ago 1.44 GB hyperledger/fabric-membersrvc x86_64-0.7.0-snapshot-5b0a7f0 41c3feac8651 6 hours ago 1.44 GB hyperledger/fabric-peer latest 44c43c14eb1c 6 hours ago 1.446 GB hyperledger/fabric-peer x86_64-0.7.0-snapshot-5b0a7f0 44c43c14eb1c 6 hours ago 1.446 GB hyperledger/fabric-javaenv latest 9967f458e2f8 9 hours ago 791 MB hyperledger/fabric-javaenv x86_64-0.7.0-snapshot-5b0a7f0 9967f458e2f8 9 hours ago 791 MB hyperledger/fabric-baseimage latest ba5a47491ea8 9 hours ago 1.424 GB hyperledger/fabric-ccenv latest ba5a47491ea8 9 hours ago 1.424 GB hyperledger/fabric-ccenv x86_64-0.7.0-snapshot-5b0a7f0 ba5a47491ea8 9 hours ago 1.424 GB hyperledger/fabric-src latest 39667ef2fa27 9 hours ago 1.418 GB hyperledger/fabric-src x86_64-0.7.0-snapshot-5b0a7f0 39667ef2fa27 9 hours ago 1.418 GB hyperledger/fabric-baseimage x86_64-0.1.0 db53d04b117c 2 weeks ago 1.39 GB```

ghaskins
2016-10-04 15:58
@lenh apologies, I just saw that you already tried the docker-tag thing too

ghaskins
2016-10-04 15:59
the core.yaml thing _might_ be because we hacked ccenv->baseimage

lenh
2016-10-04 15:59
yeah - no worries - look I'm no expert but I think you nailed earlier when you were discussing how the SDK packages and sends the deploy request

ghaskins
2016-10-04 15:59
try using fabric-peer instead of fabric-ccenv

ghaskins
2016-10-04 15:59
yeah, we need to fix that…but in the interest of getting you off the ground quick...

ghaskins
2016-10-04 15:59
we can hack it like this

ghaskins
2016-10-04 16:00
so try “docker tag …peer:latest …baseimage:latest"

ghaskins
2016-10-04 16:00
filling in the full name, of course

lenh
2016-10-04 16:00
to be honest bud - until the node SDK Ledger query issue is fixed it's all moot

ghaskins
2016-10-04 16:00
the peer image _should_ have the core.yaml in it

ghaskins
2016-10-04 16:00
ah, i am not familar with that issue

lenh
2016-10-04 16:04
Ok let me recap for sake of not causing overdue confusion / wasted effort... - I have 2 VM's (Fabric and Client) - Fabric runs fine and is based on latest (this morning I axed EVERYTHING - VM - vbox image - the lot) - client VM has node sdk installed via npm install hfc - client code works 100% (or so it seems to wrt deploy and invoke) - client code fails on query - the folks over at #fabric-sdk-node are not surprised as there are unmerged fixes needing assimilation - peer node spits out error messages BUT on the client side the deploy / invoke seems to return the expected results...

lenh
2016-10-04 16:05
```Enrolling WebAppAdmin... Enrolled JohnDoe successfully deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"} invoke chaincode ... invoke submitted successfully; results={"uuid":"bf9916aa-f111-4df4-b185-7c466206ad32"} invoke completed successfully; results={"result":"Tx bf9916aa-f111-4df4-b185-7c466206ad32 complete"}```

ghaskins
2016-10-04 16:06
that is consistent with my understanding of your environment

ghaskins
2016-10-04 16:06
i am still not convinced that your deploy/invoke is working however

lenh
2016-10-04 16:06
AHA - OK well now THAT does concern me

ghaskins
2016-10-04 16:06
(though perhaps more progress has been made on that front since the baseimage problem

ghaskins
2016-10-04 16:07
can you post the latest peer log?

ghaskins
2016-10-04 16:07
at least w.r.t. the window of time of the deploy+invoke+query

lenh
2016-10-04 16:07
my view is if it's the SDK that's got an issue with query which will be addressed - fine

lenh
2016-10-04 16:07
but if it's the environment that's not working that's a biggie

lenh
2016-10-04 16:08
yeah sure

ghaskins
2016-10-04 16:08
yeah, i suspect you have a fundamental failure to deploy

lenh
2016-10-04 16:08
where's pwd of the log

ghaskins
2016-10-04 16:08
i know query in general works, we do this in our own applications all the time

ghaskins
2016-10-04 16:08
(via the SDK, etc)

lenh
2016-10-04 16:08
if the SDK is "faking it" as you suggested last night well then I do have a problem

ghaskins
2016-10-04 16:08
honestly, i am not sure for a production-like deployment

ghaskins
2016-10-04 16:09
i am always running the peer in a terminal in devmode

ghaskins
2016-10-04 16:09
so the log just goes to the stdout

ghaskins
2016-10-04 16:09
but that log you pasted the other day was representative of what I am asking for

ghaskins
2016-10-04 16:09
so if you can get that again….

lenh
2016-10-04 16:09
ok sure

ghaskins
2016-10-04 16:09
(the one that was complaining about baseimage:latest)

lenh
2016-10-04 16:10
I'll do a fresh run - i.e. kill membersrvc / clean /var/hyperledger/production on fabric, clean /tmp/keyValStore on client, kill peer and bring everything up in clean state and dump outputs here

lenh
2016-10-04 16:10
give me a sec plse

ghaskins
2016-10-04 16:11
of course, ty

ghaskins
2016-10-04 16:12
stepping away for lunch, just @tag me when you post so I see the notice

lenh
2016-10-04 16:12
no worries - bon appetit

lenh
2016-10-04 16:14
@ghaskins - peer node startup output ```vagrant@hyperledger-devenv:v0.1.0-5b0a7f0:/hyperledger$ peer node start 16:11:31.126 [nodeCmd] serve -> INFO 002 Security enabled status: false 16:11:31.126 [nodeCmd] serve -> INFO 003 Privacy enabled status: false 16:11:31.126 [eventhub_producer] start -> INFO 001 event processor started 16:11:31.144 [chaincode] NewChaincodeSupport -> INFO 004 Chaincode support using peerAddress: 0.0.0.0:7051 16:11:31.145 [sysccapi] RegisterSysCC -> INFO 005 system chaincode (noop,http://github.com/hyperledger/fabric/bddtests/syschaincode/noop) disabled 16:11:31.146 [state] loadConfig -> INFO 006 Loading configurations... 16:11:31.146 [state] loadConfig -> INFO 007 Configurations loaded. stateImplName=[buckettree], stateImplConfigs=map[numBuckets:%!s(int=1000003) maxGroupingAtEachLevel:%!s(int=5) bucketCacheSize:%!s(int=100)], deltaHistorySize=[500] 16:11:31.147 [state] NewState -> INFO 008 Initializing state implementation [buckettree] 16:11:31.147 [buckettree] initConfig -> INFO 009 configs passed during initialization = map[string]interface {}{"numBuckets":1000003, "maxGroupingAtEachLevel":5, "bucketCacheSize":100} 16:11:31.147 [buckettree] initConfig -> INFO 00a Initializing bucket tree state implemetation with configurations &{maxGroupingAtEachLevel:5 lowestLevel:9 levelToNumBucketsMap:map[5:1601 6:8001 0:1 9:1000003 8:200001 7:40001 3:65 1:3 4:321 2:13] hashFunc:0xab1cd0} 16:11:31.148 [buckettree] newBucketCache -> INFO 00b Constructing bucket-cache with max bucket cache size = [100] MBs 16:11:31.149 [buckettree] loadAllBucketNodesFromDB -> INFO 00c Loaded buckets data in cache. Total buckets in DB = [0]. Total cache size:=0 16:11:31.149 [genesis] func1 -> INFO 00d Creating genesis block. 16:11:31.156 [consensus/controller] NewConsenter -> INFO 00e Creating default consensus plugin (noops) 16:11:31.160 [consensus/noops] newNoops -> INFO 00f NOOPS consensus type = *noops.Noops 16:11:31.160 [consensus/noops] newNoops -> INFO 010 NOOPS block size = 500 16:11:31.160 [consensus/noops] newNoops -> INFO 011 NOOPS block wait = 1s 16:11:31.162 [consensus/statetransfer] blockThread -> INFO 013 Validated blockchain to the genesis block 16:11:31.162 [nodeCmd] serve -> INFO 012 Starting peer with ID=name:"jdoe" , network ID=dev, address=0.0.0.0:7051, rootnodes=, validator=true 16:11:31.163 [rest] StartOpenchainRESTServer -> INFO 014 Initializing the REST service on 0.0.0.0:7050, TLS is disabled.```

lenh
2016-10-04 16:16
@ghaskins - then I run the enroll, deploy, invoke, query cycle from the client via the SDK. Peer output once deploy starts... ```2016/10/04 16:12:11 transport: http2Server.HandleStreams failed to receive the preface from client: EOF 16:12:19.446 [dockercontroller] deployImage -> ERRO 015 Error building images: The command '/bin/sh -c go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8' returned a non-zero code: 1 16:12:19.446 [dockercontroller] deployImage -> ERRO 016 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage ---> ba5a47491ea8 Step 2 : COPY . $GOPATH/src/build-chaincode/ ---> Using cache ---> 78bb1ebf4c91 Step 3 : WORKDIR $GOPATH ---> Using cache ---> 930ff57471de Step 4 : RUN go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 ---> Running in b60762dced32 cp: cannot stat 'src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml': No such file or directory ******************** 16:12:26.318 [dockercontroller] deployImage -> ERRO 017 Error building images: The command '/bin/sh -c go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8' returned a non-zero code: 1 16:12:26.318 [dockercontroller] deployImage -> ERRO 018 Image Output: ******************** Step 1 : FROM hyperledger/fabric-baseimage ---> ba5a47491ea8 Step 2 : COPY . $GOPATH/src/build-chaincode/ ---> Using cache ---> 78bb1ebf4c91 Step 3 : WORKDIR $GOPATH ---> Using cache ---> 930ff57471de Step 4 : RUN go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 ---> Running in a8b7df08066a cp: cannot stat 'src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml': No such file or directory ******************** 16:12:26.318 [chaincode] Launch -> ERRO 019 launchAndWaitForRegister failed Error starting container: The command '/bin/sh -c go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8' returned a non-zero code: 1 2016/10/04 16:14:11 transport: http2Server.HandleStreams failed to receive the preface from client: EOF```

lenh
2016-10-04 16:17
@ghaskins - client output prior to query fail... ```vagrant@homestead:~/Code/node_hl$ node server.js Hyperldeger REST API provider listening on port 8081 Middleware invoked... Enrolling WebAppAdmin... Enrolled JohnDoe successfully deploying chaincode; please wait ... deploy complete; results: {"uuid":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"} invoke chaincode ... invoke submitted successfully; results={"uuid":"ad948f33-1b51-49e5-a3f5-44ebc7ecbc9e"} invoke completed successfully; results={"result":"Tx ad948f33-1b51-49e5-a3f5-44ebc7ecbc9e complete"} Waiting for chain to sync...```

lenh
2016-10-04 16:17
@ghaskins - and then client side... ```querying chaincode ... Failed to query chaincode: request={"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8","fcn":"query","args":["a"]}, error=%k EventTransactionError { error: { status: 'FAILURE', msg: <Buffer 45 72 72 6f 72 3a 46 61 69 6c 65 64 20 74 6f 20 6c 61 75 6e 63 68 20 63 68 61 69 6e 63 6f 64 65 20 73 70 65 63 28 43 6f 75 6c 64 20 6e 6f 74 20 67 65 ... > }, msg: 'Error:Failed to launch chaincode spec(Could not get deployment transaction for 56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 - LedgerError - ResourceNotFound: ledger: resource not found)' } vagrant@homestead:~/Code/node_hl$```

yacovm
2016-10-04 16:18
please can you upload the text as snippets?

yacovm
2016-10-04 16:18
via the + button on the left

lenh
2016-10-04 16:19
@ghaskins - the problem of course is we can't tell if the deploy actually worked cause the query fails so I have no idea if `"chaincodeID":"56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8"` actually exists or not...

lenh
2016-10-04 16:19
@yacovm - noted...

yacovm
2016-10-04 16:19
can you run the command `/bin/sh -c go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8` locally?

yacovm
2016-10-04 16:19
what does it say?

ghaskins
2016-10-04 16:19
On mobile, but quick note that it did fail the deploy

ghaskins
2016-10-04 16:20
That is your fundamental problem

ghaskins
2016-10-04 16:20
We can fix it when I get back

yacovm
2016-10-04 16:20
oh actually it says there

ghaskins
2016-10-04 16:20
The indicator is step 4 in the first deployment log

lenh
2016-10-04 16:21
@ghaskins - OK gotcha - but that's really bad wrt to the SDK then surely?

lenh
2016-10-04 16:21
@ghaskins - never mind for now - enjoy lunch

yacovm
2016-10-04 16:25
Hey, whats the upper limit for a unit test's runtime in our project? 20min? is it per package or per TestFoo method?

ratnakar
2016-10-04 16:43
@lenh I just wrote a quick program https://github.com/ratnakar-asara/hello-blockchain, can you try this as per the instructions, let us know if it works

lenh
2016-10-04 16:59
@ratnakar - standby plse

ghaskins
2016-10-04 17:01
@lenh w.r.t. SDK, the lack of a closed loop response is limiting, yes, but its also a known limitation and being actively worked on

ghaskins
2016-10-04 17:01
im not quite sure why your deployment is failing now that you hacked the docker tag, as I checked a build here and I can see the core.yaml

ghaskins
2016-10-04 17:01
let me study the log again

lenh
2016-10-04 17:02
understood - I understand things are fluid in these early days

ghaskins
2016-10-04 17:02
i just tried this:

ghaskins
2016-10-04 17:02

ghaskins
2016-10-04 17:03
so, it seems like the basic files are there

ghaskins
2016-10-04 17:03
now its a question of why that build instruction failed

lenh
2016-10-04 17:03
but does make it "a little challenging" trying to get a dev workflow going

ghaskins
2016-10-04 17:03
yes, understood, and sorry for the trouble

ghaskins
2016-10-04 17:03
basically, it “works” as long as nothing goes wrong :wink:

lenh
2016-10-04 17:03
no need to apologise

ghaskins
2016-10-04 17:03
which is part of the reason its made it this long without getting fixed

ghaskins
2016-10-04 17:04
my short term goal is to get you up and running, even if its limping and via nasty hacks :wink:

lenh
2016-10-04 17:06
appreciated...

ghaskins
2016-10-04 17:06
ok, so part of the problem is the "src/build-chaincode/vendor/“ in your path

ghaskins
2016-10-04 17:06
not sure where that is coming from yet

ghaskins
2016-10-04 17:07
i would have expected that to be src/github.com/hyperledger….

ghaskins
2016-10-04 17:07
not with the build-chaincode thing interjected

ratnakar
2016-10-04 17:07
``` RUN go install build-chaincode && cp src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml $GOPATH/bin && mv $GOPATH/bin/build-chaincode $GOPATH/bin/56e9be9d65e603a249e047f0aa08b17fa7889a6aca263d18270a80b13b7ec8f8 ---> Running in b60762dced32 cp: cannot stat 'src/build-chaincode/vendor/github.com/hyperledger/fabric/peer/core.yaml': No such file or directory ``` We saw this error many times, where chaincode is missing vendor folder which is required while peer is building the chaincode

ghaskins
2016-10-04 17:07
ultimately, that is what is failing…im just not sure what is driving that to be there in the first place

ghaskins
2016-10-04 17:08
that doesnt make sense to me, ill need to dig deeper

ghaskins
2016-10-04 17:09
ah, its coming from the SDK

ghaskins
2016-10-04 17:09
that seems completely broken to me

ghaskins
2016-10-04 17:09
furthering my argument that the SDK should not be in the Dockerfile business

ghaskins
2016-10-04 17:09
i digress

ghaskins
2016-10-04 17:09
lets see what we have to hack to fix this for now

ratnakar
2016-10-04 17:10
with current implementation in NodeSdk , it packages chaincode along with the vendor packages and sends the same to peer , then peer will extract it and comiple chaincode based on the Dockerfile

ghaskins
2016-10-04 17:10
understood


ghaskins
2016-10-04 17:20
right

ghaskins
2016-10-04 17:20
basically that whole mechanism needs to be revamped

ghaskins
2016-10-04 17:21
im actually confused how it ever worked through

ghaskins
2016-10-04 17:21
who installed the src/build-chaincode/vendor folder into the tarball?

ghaskins
2016-10-04 17:21
im assuming the SDK

ghaskins
2016-10-04 17:22
but if so, why is the core.yaml missing now?

ratnakar
2016-10-04 17:23
Yes it is SDK does that , core.yaml file is missing because the chaincode folder must contain vendor folder as well whcih is required for peer


ghaskins
2016-10-04 17:23
so if I understand you correctly, the impetus is on the chaincode developer to provide this

ghaskins
2016-10-04 17:23
?

ratnakar
2016-10-04 17:24
If you see the node-sdk based unit tests for each example they are cloning/copying the whole hyperledger structure to chaincode folder

ghaskins
2016-10-04 17:24
before netmode deploy will work

ratnakar
2016-10-04 17:24
Yes you are right

ghaskins
2016-10-04 17:24
so, that means if @lenh makes his deployment compliant, his will work too

lenh
2016-10-04 17:25
sorry on a call

ghaskins
2016-10-04 17:25
np

ratnakar
2016-10-04 17:25
Yes thats right .. that is what I was trying to convey

ghaskins
2016-10-04 17:26
@ratnakar got it

ghaskins
2016-10-04 17:26
i still think this all needs an overhaul…;) but that said, sounds like we can work around this for now by complying

ratnakar
2016-10-04 17:29
Seems there is a task exist already on this (I don't have the details though) , once that is available , node app developer need not bother about maintaining vendor code etc.,


ghaskins
2016-10-04 17:30
@ratnakar thank you for that

ghaskins
2016-10-04 17:31
@lenh ^^^^

ghaskins
2016-10-04 17:31
I do believe if you follow the instructions in that link, we should at least get past the “core.yaml” error you are seeing

ghaskins
2016-10-04 17:32
(and hopefully all the way to deployment, but who knows what else we’ll run into ;)

lenh
2016-10-04 17:32
sorry guys - on a standup call

ghaskins
2016-10-04 17:32
no worries, just there for when you return

lenh
2016-10-04 18:37
sorry - just been roasted on my call... followed @ratnakar got this...

lenh
2016-10-04 18:37
```vagrant@homestead:~/hello-blockchain$ ls app.js config.json README.md src vagrant@homestead:~/hello-blockchain$ node app.js ERROR: failed to register admin, Error : {"code":14,"metadata":{"_internal_repr":{}}}```

ratnakar
2016-10-04 18:45
can you delete the crypto materials from `/tmp/keyValStore` folder , restart membersrv and peer and run the program again `DEBUG=hfc node app.js`

lenh
2016-10-04 18:50
sorry guys - gone past 22:30 here - been days trying to get this working and now I want to spend some time with my wife...

lenh
2016-10-05 08:49
@ghaskins @ratnakar SUCCESS!

lenh
2016-10-05 08:49
thanks a mill to both of you for the persistent assistance that eventually got it working for me

hgabor
2016-10-05 08:50

lenh
2016-10-05 08:51
I think I now know why it kept failing - the chaincode was not located in the path of the node app

lenh
2016-10-05 08:52
@hgabor - thanks and noted

hgabor
2016-10-05 08:54
it is just a first step, I will continue with the 2nd

ghaskins
2016-10-05 12:15
@lenh awesome! glad to hear its working

lenh
2016-10-05 12:16
thanks for all the help...

ghaskins
2016-10-05 12:30
@lenh yw…btw, when you talked about the “ledqer query problem” the other day….i assume that was a result of the failed deployment? or is there some other lurking issue we need to address?

lenh
2016-10-05 12:30
yup

ghaskins
2016-10-05 12:30
ok, cool

lenh
2016-10-05 12:30
querying the chaincode works 100% now that deploy issue has been solved...

ghaskins
2016-10-05 12:31
nice, ok

yogigolle
2016-10-06 00:55
has joined #fabric-dev

yacovm
2016-10-06 14:40
Hey, so what's the status of the BDD now? are all BDD tests now converted to golang?

david.stark
2016-10-06 17:52
We are looking at moving from the 0.5 release to the 0.6 release. In 0.5 if a transaction is sent (invoke) to the blockchain and it results in an error we can see this by watching the events and in the block event under non hash data each transaction is listed and if it resulted in error there is an error object in it with the error. In 0.6 if a transaction results in an error there is no record for it in the non hash data. Is this a bug, or intentional? If intentional how is a client now supposed to be able to see if a transaction it has submitted has resulted in an error?

mahoney
2016-10-06 19:41
has joined #fabric-dev

mart0nix
2016-10-07 13:09
has joined #fabric-dev

mart0nix
2016-10-07 13:12
guys I need some advice about data modelling in fabric

mart0nix
2016-10-07 13:12
I'm basically receiving JSON documents that I need to parse and store (and be able to query later) in a normal web stack I'd creat 5-6 SQL tables, parse the JSON and then do SQL queries right now I'm debating if I should use the shim.Table interface (it looks like it supports KEYs - at least it has the keyword there I don't know if those fields are actually being indexed right now) OR I should model my data layer as regular GO structs with embedded []lists for relationships

mart0nix
2016-10-07 13:14
I only have write /read operations ( i don't have to modify/edit/delete records)

donovanhide
2016-10-07 13:40
Anyone here who can help with Linux Foundation ID’s? I created one using my Github account, but I need a password to log into Gerrit. If I try to reset my password via email, it says I must enter my password to accept the new password :slightly_smiling_face:

ghaskins
2016-10-07 13:41
@donovanhide I think there are problems trying to use the SSO logins

ghaskins
2016-10-07 13:41
just create a native LFID

ghaskins
2016-10-07 13:41
I ran into this too several months back

ghaskins
2016-10-07 13:41
@ry ^^^^

ry
2016-10-07 13:41
has joined #fabric-dev

donovanhide
2016-10-07 13:41
@ghaskins thanks, will do!

donovanhide
2016-10-07 13:44
@ry unfortunately there’s now both a clash on my username and email address. Can you help?

donovanhide
2016-10-07 13:46
It’s not a huge issue, but gorocksdb needs updating in the vendor folder to function with the latest homebrew rocksdb ```govendor update http://github.com/tecbot/gorocksdb``` solved the problem. If somone else wants to drive this through gerrit, I’d be very much appreciative :slightly_smiling_face:

donovanhide
2016-10-07 13:55

garisingh
2016-10-07 14:54
@donovanhide - I believe that we might have had some issues in the code even though it might compile with the latest version of rocksdb / gorocksdb (but not sure)

donovanhide
2016-10-07 15:16
@garisingh Any hints on what the issue might have been? Test failures?

garisingh
2016-10-07 16:01
I honestly don't remember - I just seem to recall that there was some reason we were sticking with rocksdb 4.1. But maybe it was actually just because thats what gorcoksdb supported at the time

ccooper21
2016-10-08 16:57
has joined #fabric-dev

kostas
2016-10-08 23:08
@garisingh quick question:

kostas
2016-10-08 23:09
How do you make your git commits show up on the relevant issue in JIRA, as shown here? https://jira.hyperledger.org/browse/FAB-541

kostas
2016-10-08 23:11
That's neat. I added links to the JIRA issues in my commit messages but that's not what triggers it apparently.

muralisr
2016-10-08 23:13
@kostas I just put FAB-XXX either in the subject … or maybe in a line in the comments

kostas
2016-10-08 23:21
Cool, so it's similar to GitHub. I'll try it out next time, thanks.

garisingh
2016-10-08 23:32
@kostas - no trick - I manually do it

kostas
2016-10-09 00:58
@garisingh Can you elaborate? My "Git Commits" tab looks like this.


ry
2016-10-09 03:33
@kostas they don't show up until the commits are merged

kostas
2016-10-09 12:24
A-ha. Got it know, thanks.

yacovm
2016-10-10 12:43
Hey all. We made a demo vid of our gossip component, you can check it out in the #fabric-gossip-dev channel.

tuand
2016-10-10 12:54
@markparz ^^^

markparz
2016-10-10 12:55
has joined #fabric-dev

nhrishi
2016-10-10 15:55
Hi, Quick question : what is the block memory size in hyperledger fabric (by default)?

claytonsims
2016-10-10 16:06
has joined #fabric-dev

weeds
2016-10-10 16:07
has joined #fabric-dev

keithsmith
2016-10-11 12:26
@nhrishi @tuand This is best answered by Tuand, but from looking at the defaults in fabric/consensus/pbft/config.yaml, it looks like the default batchsize is 500 with a default timeout of 1 sec, if that is the question

keithsmith
2016-10-11 12:28
Also I wanted to mention that for anyone interested, the membership-services channel is being used to provide updates pertaining to membership services. I just posted an update with what the membership services squad is working on

tuand
2016-10-11 13:12
@nhrishi it's not by memory size per se ... as Keith mentioned, batchsize sets how many transactions are aggregated to go through consensus, executed and written to one block. In addition, if the timer fires, we aggregate the current number of transactions in queue even if we have not reached batchsize

nhrishi
2016-10-11 16:57
@keithsmith: @tuand Thanks for clarification ..also do you agree that the block memory size for batch of transaction in the block will vary depending on the content or fields in the transaction ? Want to understand it for disk size requirements analysis for each node (VP).

keithsmith
2016-10-11 17:05
@nhrishi Correct, the actual block memory size will vary based on transaction size

nhrishi
2016-10-11 17:18
Thanks @keithsmith

kostas
2016-10-11 21:03
@ghaskins: Any news on the Go 1.7 front?

ghaskins
2016-10-11 21:04
ive submitted the patches, waiting for maintainers to merge

ghaskins
2016-10-11 21:04
see CRs 1471 and company

ghaskins
2016-10-11 21:05
it all passes the UT/behave runs though

kostas
2016-10-11 21:05
Wonderful, thanks.

ghaskins
2016-10-11 21:06
actually, i still need a rebase, but waiting for 1491 1493 to go in first

ghaskins
2016-10-11 21:06
but after that, 1471 should be ready to go in

humblealex
2016-10-12 02:33
has joined #fabric-dev

humblealex
2016-10-12 02:34
Maybe it is a bug? We were developing a chaincode trying to read certificatepaires from CA, so we used the ReadCertificatePair function from /membersrvc/ca/ecap.go through grpc connection.We got nothing.So we looked at readCertificates function in ca.go and noticed that two columns are being pulled out (cert, kdfey) while in ReadCertificatePair, rows.Scan(&raw) indicates one column. So which part should be fixed? or are there any other ways around of doing this?

akihikot
2016-10-12 06:34
has joined #fabric-dev

georgeo
2016-10-12 15:50
has joined #fabric-dev

jdockter
2016-10-12 16:49
has joined #fabric-dev

ashishkel
2016-10-13 04:49
Hi All, We are using events to detect the business logic events from the Chaincode. We used the event Client program available in example, as the test program. And we used our own chaincode to create the events. And the API used in the Chaincode was `err = stub.SetEvent("evtsender3", []byte(tosend))` And the way we used it is as below `tosend := "Event from Invoke_user"` `err := stub.SetEvent("evtsender1", []byte(tosend))` ` delay := 5000 * time.Millisecond` ` time.Sleep(delay)` `tosend = "Event from Invoke_user with args :"` `for _, s := range args {` ` tosend = tosend + "," + s` `}` `err = stub.SetEvent("evtsender2", []byte(tosend))`

ashishkel
2016-10-13 04:50
But on the client, only second event is being received. i.e., *evtsender2*


ashishkel
2016-10-13 04:51
Is this the expected behavior ?

ashishkel
2016-10-13 04:52
I had introduced delay to see whether its getting lost..

ashishkel
2016-10-13 04:53
I was using same event Names before, then changed that to evtsender1 and evtsender2 respectively.

ashishkel
2016-10-13 04:53
still not able to get hold of that first event.. :disappointed:

muralisr
2016-10-13 11:54
@ashishkel only one event from one Invoke supported ( @pmullaney )

ashishkel
2016-10-13 11:55
@muralisr , ohkay , Thanks for confirming

pmullaney
2016-10-13 13:11
@ashishkel : yes, that is the current behavior one event per invoke

pushpalatha
2016-10-14 07:31
Hi all, I have the latest gerrit code . Facing the following issue while make peer. Any idea? Please help. Pushpalathas-MacBook-Pro:fabric pushpa$ make peer build/bin/peer CGO_CFLAGS=" " CGO_LDFLAGS="-lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" GOBIN=/Users/pushpa/gocode/src/github.com/hyperledger/fabric/build/bin go install -ldflags "-X http://github.com/hyperledger/fabric/metadata.Version=0.7.0-snapshot-551fa9b" http://github.com/hyperledger/fabric/peer # http://github.com/hyperledger/fabric/vendor/github.com/Sirupsen/logrus vendor/github.com/Sirupsen/logrus/terminal_darwin.go:10: ioctlReadTermios redeclared in this block previous declaration at vendor/github.com/Sirupsen/logrus/terminal_bsd.go:7 vendor/github.com/Sirupsen/logrus/terminal_darwin.go:12: Termios redeclared in this block previous declaration at vendor/github.com/Sirupsen/logrus/terminal_bsd.go:9 # http://github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb vendor/github.com/tecbot/gorocksdb/options.go:328: not enough arguments in call to _Cfunc_rocksdb_options_set_compression_options make: *** [build/bin/peer] Error 2

yacovm
2016-10-14 09:03
Hey all, what's the status of merging convergence and master?

cbf
2016-10-14 12:37
@yacovm not clear… @ghaskins created a list of changesets that had no merge conflicts… think we were planning on applying those in batches

cbf
2016-10-14 12:37
then there were 36 remaining changesets that needed merge conflict resolution

yacovm
2016-10-14 12:40
all I need is for the convergence branch to have the protobuf+gRPC version like the master branch has

yacovm
2016-10-14 12:40
(in the vendor)

yacovm
2016-10-14 12:41
from what I understood from him, that'll be included, so that's good.

yacovm
2016-10-14 12:43
oh and btw :+1: for you email proposal of context-based maintainers

ghaskins
2016-10-14 12:55
@cbf @yacovm working with others on the merge in the #fabric-reconcile channel

ghaskins
2016-10-14 12:56
will send out status but I estimate we should have a CR for the convergence branch that brings all the relevant master changes in by EOD

ghaskins
2016-10-14 12:56
we can then decide timing on when/if convergence collapses back to master independently

ghaskins
2016-10-14 12:57
and yes, +1 for the maintainer context

yacovm
2016-10-14 12:57
as long as its EOD and not EOL it's GTM :slightly_smiling_face:

cbf
2016-10-14 13:53
LOL

n.ohagan
2016-10-14 13:55
has joined #fabric-dev

n.ohagan
2016-10-14 15:26
@n.ohagan has left the channel

weeds
2016-10-14 15:51
ha ha @yacovm... and @ghaskins I know you guys in the community are working hard at this- if we can get by EOD- will be exciting

ghaskins
2016-10-14 15:52
@muralisr has the basic merge completed and has begin running it through the UTs etc

ghaskins
2016-10-14 15:52
I think we had to drop a small number of changes that we will keep careful track of, and let the SMEs handle at a later time

ghaskins
2016-10-14 15:52
specifically regarding the java shim and bdd tests

ghaskins
2016-10-14 15:53
and to be clear: “EOD” is relative to EDT :wink:

ghaskins
2016-10-14 15:53
and also, an estimate

yacovm
2016-10-14 15:54
what about the vendor folders?

muralisr
2016-10-14 15:59
@yacovm we didn’t have to “resolve” vendor conflicts .. so assume merge went thru for them ok. but we’ll have to run thru tests

muralisr
2016-10-14 15:59
so @ghaskins after a couple of minor changes post merge, fabric builds and peer comes up

yacovm
2016-10-14 16:01
So vendor folders of convergence are now these of master, right?

yacovm
2016-10-14 16:01
Just making sure...

ghaskins
2016-10-14 16:03
to be clear, vendor changes that were applied to master after the convergence branch point have now been applied to convergence (in our working tree, not pushed to gerrit yet)

ghaskins
2016-10-14 16:04
that doesnt necessarily mean equivalence,

ghaskins
2016-10-14 16:04
(for instance, someone might have made other vendor updates in convergence

ghaskins
2016-10-14 16:04
i didnt check

ghaskins
2016-10-14 16:04
but I also think that is what you are concerned with @yacovm

muralisr
2016-10-14 16:42
@yacovm `go build` on packages in gossip/ succeeded if that means anything...

yacovm
2016-10-14 16:45
how? The pb.go files of gossip were compiled with protobuf 3beta, and the vendor folder nlw should have protobuf version 3. Is that backward compatible?

muralisr
2016-10-14 16:45
I did a make protos first

yacovm
2016-10-14 16:45
I think it's a good idea to delete all pb go files abyway and compile them with devenv/compile_protos.sh

yacovm
2016-10-14 16:46
What do you think?

yacovm
2016-10-14 16:47
I think it's worth to check that pb.go files in convergence now are v3 and not 3beta

muralisr
2016-10-14 16:47
agreed

ghaskins
2016-10-14 17:22
@yacovm i recompiled all the protos in convergence as part of the merge

ghaskins
2016-10-14 17:23
e.g. brought your patch in, got the environment updated with the new protoc, did a “make protos”, and refreshed the patch

ghaskins
2016-10-14 17:23
that isnt to say that we havent missed something, we are still working through validation

ghaskins
2016-10-14 17:25
long story short: this is a high touch merge

ghaskins
2016-10-14 17:25
we are looking patch by patch

yacovm
2016-10-14 17:25
Thanks for the updates and I know I'm being over-paranoid than usual

ghaskins
2016-10-14 17:26
its warranted

ghaskins
2016-10-14 17:26
its a big merge

ghaskins
2016-10-14 17:26
we are being careful, and we are experienced in such matters, but there is lots of room for error

ghaskins
2016-10-14 17:27
i hope we can get through this, stablize things, and then make sure this doesnt happen again :wink:

weeds
2016-10-14 19:49
I met with team on membership-services today and put some background for those in interest.

weeds
2016-10-14 19:50
in the membership-services channel

muralisr
2016-10-14 21:01
just a status update … we did the master->convergence merge and @ghaskins has pushed it to `https://github.com/ghaskins/hyperledger-fabric` under branch `convergence-merge-for-murali`

muralisr
2016-10-14 21:01
about to test

muralisr
2016-10-14 22:43
after a few false alarms `make peer-image` and a sniff test of core/chaincode worked proceeding to full unit tests

jonathanlevi
2016-10-15 01:45
---

jonathanlevi
2016-10-15 01:45
We can’t cut a release of v0.6 without https://gerrit.hyperledger.org/r/#/c/1607/

jonathanlevi
2016-10-15 01:46
Seems as if the (unrelated) failure has been there for a few days (regardless of TLS/ACA, etc).

jonathanlevi
2016-10-15 01:48
Separately, I have just merged https://gerrit.hyperledger.org/r/#/c/1747 which contains a fix to the underlying chaincode_example04…. and does seem to work in `master`.

jonathanlevi
2016-10-15 01:50
One solution is to cherry-pick the working version/code of 1747 and submit it (either under https://gerrit.hyperledger.org/r/#/c/1759 or separately)…

jonathanlevi
2016-10-15 01:50
But we all really need a working v0.6 branch (again, regardless of 1607).

jonathanlevi
2016-10-15 01:53
Only once the branch builds/tests successfully… I will rebase the changes from 1607 onto it. Will be happy to review patchsets. We can all see it passing now in master. We can get there. PM me.

muralisr
2016-10-15 01:55
what do you need ? :slightly_smiling_face:

jonathanlevi
2016-10-15 01:55
We need someone to pick up the changes from 1747 that I have merged to master...

muralisr
2016-10-15 01:55
seems like 1607 is not passing verification ?

jonathanlevi
2016-10-15 01:55
Yup, exactly.

jonathanlevi
2016-10-15 01:56

jonathanlevi
2016-10-15 01:56
We need to get the example_chaincode04 to build successfully in the v0.6 branch.

muralisr
2016-10-15 01:57
ok

jonathanlevi
2016-10-15 01:57
I don’t know how people worked with this branch over the last 3 days, but that’s a separate story.

jonathanlevi
2016-10-15 01:58
We have a crucial fix (which is the last ‘must have’ for v0.6), that is 1607. But we must have a working v0.6.

muralisr
2016-10-15 01:58
ok

jonathanlevi
2016-10-15 01:59
Jim Zhang wrote to me that he will work on this too (soon). But I’ll review whatever builds.

muralisr
2016-10-15 01:59
ok

muralisr
2016-10-15 01:59
let me check out 0.6

jonathanlevi
2016-10-15 01:59
Thank you.

muralisr
2016-10-15 02:31
I’m confused… the originial (Base) hash was correct

muralisr
2016-10-15 02:32
when I changed it back to it, it worked

muralisr
2016-10-15 02:34
I’m going to put back the original hash and see what happens


muralisr
2016-10-15 02:54
let see if CI runs ok

muralisr
2016-10-15 10:10
@jonathanlevi the above went through CI fine

muralisr
2016-10-15 11:27
@jonathanlevi @jzhang 1759 did the identical thing …abandoned 1765 for 1759… @garisingh has more info on state of 0.6

garisingh
2016-10-15 11:37
reverifying 1607 now that 1759 is in

garisingh
2016-10-15 11:37
hopefully that will work

ashutoshkumar
2016-10-15 12:45
@garisingh : Looks like build failed.

garisingh
2016-10-15 12:46
yeah - change needs to be rebased

garisingh
2016-10-15 12:55
I took care of it - hopefully this (finally) works

ashutoshkumar
2016-10-15 13:36
I Looked at new changes for changeset for 1607. It seems fine to me.

jzhang
2016-10-15 13:52
has joined #fabric-dev

jzhang
2016-10-15 13:55
@muralisr so the change b/w 1759 (observing failure of mismatched hash in local testing both on my machine and @cbf's) and 1767 (reverting it back because the hash was calculated differently on the build machine) took a lot of time getting right. shouldn’t the example be updated to take the target hash as an input parameter?

muralisr
2016-10-15 13:55
@jzhang that’s exactly what example05 does

jzhang
2016-10-15 13:56
but we also should update example04, to avoid further confusion around this

jzhang
2016-10-15 13:56
not sure what caused the hash to be different...

muralisr
2016-10-15 13:56
hang on :slightly_smiling_face: ….

muralisr
2016-10-15 13:56
example04 is to make sure the hash does not change if example04 was not modified

muralisr
2016-10-15 13:57
it can get altered for two reasons

muralisr
2016-10-15 13:57
1) the code changes

muralisr
2016-10-15 13:58
2) new files get added to the dir (for example, if you built the exe for running in —peer-chaincodedev mode, the exe will be in the folder causing hash to change).. another example I think was some left over files from git (@cbf may recall that better ?)

muralisr
2016-10-15 13:59
3) <this should NEVER happen and is the purpose of the chaincode04> …. nothing changed in example02 folder but the hash is somehow different

cbf
2016-10-15 14:00
there's a patch that was merged to master by gong su - fixes this

cbf
2016-10-15 14:01
was merged last night

cbf
2016-10-15 14:01
am on phone soncan't paste

muralisr
2016-10-15 14:01
@cbf will look

jzhang
2016-10-15 14:03
so 1607 was kicked off by Gari earlier, already went past the previous failure point (with the hash value in cc2cc).

jzhang
2016-10-15 14:04
although I’m not sure we’ve weeded out all the build errors, yesterday locally I was seeing this after fixing all the other errors:

jzhang
2016-10-15 14:04

muralisr
2016-10-15 14:05
@cbf that merge by gong su defeats the whole purpose of chaincode example 04

muralisr
2016-10-15 14:05
its essentially chaincode example05 now

muralisr
2016-10-15 14:05
I’d note that this type of failures in chaincode example 04 is few and far between and has ALWAYS been human error

jzhang
2016-10-15 14:05
btw, latest build just failed in crypto package tests

jzhang
2016-10-15 14:10
13:59:08 --- FAIL: TestParallelInitClose (0.00s) 13:59:08 crypto_test.go:172: Failed registerting userthread.

jonathanlevi
2016-10-15 14:26
@muralisr (good morning)

jonathanlevi
2016-10-15 14:27
@jzhang: Yes, we still don’t have a working base branch for v0.6

jonathanlevi
2016-10-15 14:28
Onto which we can merge 1607. We need a working v0.6.

muralisr
2016-10-15 14:28
@jonathanlevi hey, gm

jonathanlevi
2016-10-15 14:29
I think that the top priority (and thanks for your help since last night!) is to get a working v0.6

jonathanlevi
2016-10-15 14:29
We can discuss `master` a bit later, if that’s OK?

muralisr
2016-10-15 14:29
ok sure

jonathanlevi
2016-10-15 14:29
I’m really concerned.

muralisr
2016-10-15 14:30
about ?

jonathanlevi
2016-10-15 14:30
The state of v0.6 over the last few days.

jonathanlevi
2016-10-15 14:30
We should stabilize it.

jonathanlevi
2016-10-15 14:30
(We wanted to take a cut of it, and tag for the v0.6 release)

muralisr
2016-10-15 14:31
understand… I have not checked. I’d have assumed very little is going into 0.6 ?

muralisr
2016-10-15 14:32
ok. never mind :slightly_smiling_face:

jonathanlevi
2016-10-15 14:34
Yes, relatively little, but the base is broken.

jonathanlevi
2016-10-15 14:35
I/we can’t merge anything onto it.

muralisr
2016-10-15 14:38
forgive me if I’m going treading know issues/ground…. but I see the with he latest 0.6 merge CI jobs have failed but the jobbuilder has +1 verified it

muralisr
2016-10-15 14:38
is that known/ok ?

jonathanlevi
2016-10-15 14:51
It’s not OK, no. When we have failures, things should fail miserably….

jonathanlevi
2016-10-15 14:51
[That’s my take, at least]

ramesh
2016-10-15 15:46
@muralisr can you give me the patch set number to verify.. This is what happens in CI, CI sends +1 or -1 to unit-test, behave and nodesdk to gerrit after execution but we are forcibly skipping voting result of nodesdk and behave jobs as we are seeing inconsistent failures..

jonathanlevi
2016-10-15 15:49

jonathanlevi
2016-10-15 15:49
It states, for example, verified (right?)

jonathanlevi
2016-10-15 15:50
But the underlying tests fail (miserably)

ramesh
2016-10-15 15:50
yes verified with -1 status

ramesh
2016-10-15 15:51
meaning unit-tests are failed..

ramesh
2016-10-15 15:52
+1 for success

jonathanlevi
2016-10-15 15:53
I see. Verified = built + unit tests.

jonathanlevi
2016-10-15 15:54
And the -1 is for the results of the entire test?

ramesh
2016-10-15 15:55
No Verified doesn't have any meaning there.. It just indicates the result of the job

ramesh
2016-10-15 15:56
similar to this ```Code-Review +2 Christopher Ferris Jonathan Levi```

jonathanlevi
2016-10-15 16:21
Got you. Here’s what I suggest.

jonathanlevi
2016-10-15 16:22
What was the last successful build (by the CI) of the v0.6 branch?

jonathanlevi
2016-10-15 16:22
By successful I mean “the full shebang”. Build/compile/unit-tests/bdd/everything...

jonathanlevi
2016-10-15 16:23
It is easy to confirm that the current/latest v0.6 is broken, regardless of 1607.

jonathanlevi
2016-10-15 16:24
I want to look backtrack what merges started breaking it. That might be the easier way to go about it.

jonathanlevi
2016-10-15 16:24
(there weren’t that many changes merged to v0.6 anyway, Murali is right)

muralisr
2016-10-15 16:26
https://gerrit.hyperledger.org/r/#/c/1269/ - last successful unit-tests run

muralisr
2016-10-15 16:26

muralisr
2016-10-15 16:28
but 1475 was just docs so may be redherring

jonathanlevi
2016-10-15 16:28
Yes, I see it.

jonathanlevi
2016-10-15 16:29
And since 1475 (documentation changes) did it continuously fail?

jonathanlevi
2016-10-15 16:29
That’s Oct 4th.

muralisr
2016-10-15 16:29
ignore 1475 please

jonathanlevi
2016-10-15 16:30
OK, ignored. So the last successful unit-test run was after the merge of 1269.

jonathanlevi
2016-10-15 16:30
Is that correct?

muralisr
2016-10-15 16:30

muralisr
2016-10-15 16:30
can you double check ?

jonathanlevi
2016-10-15 16:31
Thanks. Looking.

jonathanlevi
2016-10-15 16:32
Nope. That wasn’t successful.

jonathanlevi
2016-10-15 16:32
We skipped it, to save time.

jonathanlevi
2016-10-15 16:32
So 1269 is the latest successful build, so far?

jonathanlevi
2016-10-15 16:33
(ignoring 1757 which I have manually skipped)

jonathanlevi
2016-10-15 16:33
That’s the last time we saw a working branch v0.6?

muralisr
2016-10-15 16:34
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F2PRFRV8R/pasted_image_at_2016_10_15_12_33_pm.png and commented: thats 1757 … the “SUCCESS” is a successful unit test run

jonathanlevi
2016-10-15 16:34
@ramesh?

muralisr
2016-10-15 16:35
but the other ones are bad… not sure why they were skipped

ramesh
2016-10-15 16:36
@muralisr @jonathanlevi Unit-tests are successful https://gerrit.hyperledger.org/r/#/c/1767/ ( this is verify job)

ramesh
2016-10-15 16:37
@jonathanlevi @muralisr as I mentioned earlier we don't have merge jobs for v0.6 branch.. But I could see latest verify job passed

jonathanlevi
2016-10-15 16:38
Yes, that’s part of the problem (or at least, making it a bit more difficult… at first).

jonathanlevi
2016-10-15 16:38
We can/may have a bad merge that fails… but we can’t see it, right?

jonathanlevi
2016-10-15 16:39
I may have a patchset which builds/tests successfully, but after a merge to the branch, the branch gets broken and we can’t see it right?

ramesh
2016-10-15 16:39
yes

jonathanlevi
2016-10-15 16:39
OK. I am reverifying both.

ramesh
2016-10-15 16:40
I just configured jenkins job for v0.6 branch in sandbox environment https://jenkins.hyperledger.org/sandbox/job/fabric-unit-tests/1/console

jonathanlevi
2016-10-15 16:41
Many thanks Ramesh!

jonathanlevi
2016-10-15 16:41
Just to say, that I (we) can reproduce the failure of the v0.6 branch locally. But still, this is very helpful.

jonathanlevi
2016-10-15 16:41
I’m not going to sign off a release that just `worked on my machine` :wink:

jonathanlevi
2016-10-15 16:42
We, I should say.

muralisr
2016-10-15 16:43
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F2PR1NF7W/pasted_image_at_2016_10_15_12_42_pm.png and commented: @ramesh @jonathanlevi I must be missing something… none of the links above tell me that unit tests passed for 1757

muralisr
2016-10-15 16:43
I mean 1767

jonathanlevi
2016-10-15 16:43
Yes, same here.

jonathanlevi
2016-10-15 16:44

jonathanlevi
2016-10-15 16:44
(which is/was the reverting of the hash code fix, right?)

ramesh
2016-10-15 16:44

ramesh
2016-10-15 16:45
but please note this is before merge result

muralisr
2016-10-15 16:45
ok

ramesh
2016-10-15 17:10

muralisr
2016-10-15 17:11
ok

muralisr
2016-10-15 17:12

muralisr
2016-10-15 17:12
by latest commit you mean https://gerrit.hyperledger.org/r/#/c/1767/ right @ramesh ?

ramesh
2016-10-15 17:13
yes @muralisr

muralisr
2016-10-15 17:14
ok

jonathanlevi
2016-10-15 17:35
So, we are running (reverify) 1767.

jonathanlevi
2016-10-15 17:37
Other than that, the last patchset that has passed successfully for branch `v0.6` is https://gerrit.hyperledger.org/r/#/c/1269

jonathanlevi
2016-10-15 17:38
We are talking `Sep 27, 8:17AM`, merged on `Oct 6, 11:52AM`

jonathanlevi
2016-10-15 17:38
---

jonathanlevi
2016-10-15 17:38
Let’s see what the latest build/reverify of v0.6 (patchset 1767) yields.


jonathanlevi
2016-10-15 17:42
SUCCESS ?

jonathanlevi
2016-10-15 17:42
---

jonathanlevi
2016-10-15 17:43
What’s going on?!

jonathanlevi
2016-10-15 17:48
@jzhang, @ashutoshkumar, @ramesh, @muralisr: we need to be able to isolate the issue.

jonathanlevi
2016-10-15 17:49
Can somebody fetch and build a clean version of v0.6 (even locally)?

jonathanlevi
2016-10-15 17:49
[Regardless of Jenkins]

jonathanlevi
2016-10-15 17:50
And then, can somebody (else) pick up a clean version of the latest 1607 patch?

ramesh
2016-10-15 17:50
I just did and it failed

jonathanlevi
2016-10-15 17:50
Same for me. Both fail locally on my machine.

jonathanlevi
2016-10-15 17:50
I don’t know how this code passes on the CI.

ramesh
2016-10-15 17:51
```17:34:54.715 [chaincode] processStream -> ERRO 02c Error handling chaincode support stream: stream error: code = 1 desc = "context canceled" --- FAIL: TestChaincodeInvokeChaincode (141.61s) exectransaction_test.go:797: TestChaincodeInvokeChaincode starting db_test_exports.go:47: Creating testDB exectransaction_test.go:851: deployed chaincode_example02 got cID1:path:"http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" name:"7991dbbf981f9127412cd9fa9698a0278fe3e59fd84ac25c479a52f6d277290a6c571abfe5e5c9f472fe9bbad32e40a1e4b0096399bd433d96e815a36a8dafe7" , chaincodeID1:7991dbbf981f9127412cd9fa9698a0278fe3e59fd84ac25c479a52f6d277290a6c571abfe5e5c9f472fe9bbad32e40a1e4b0096399bd433d96e815a36a8dafe7 exectransaction_test.go:888: Error invoking <44d53a299f3f92fafcb0452877148f5d699247f20caa8756bf204d829338f73ee0a8168d8060a090330fd56cb770c3daa9dece75064532e2b2b2ca731e3f4ff6>: Error invoking chaincode: Transaction or query returned with failure: [5c12b335-fb72-433d-b2fe-f592a4f660da]Chaincode handler FSM cannot handle message (ERROR) with payload size (269) while in state: ready 17:34:57.707 [chaincode] NewChaincodeSupport -> INFO 02d Chaincode support using peerAddress: 0.0.0.0:21212 getting deployment spec for chaincode spec: type:GOLANG chaincodeID:<path:"github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" > ctorMsg:<args:"init" args:"a" args:"100" args:"b" args:"200" > ```

jonathanlevi
2016-10-15 17:52
Yup, same here. With:

jonathanlevi
2016-10-15 17:53

jonathanlevi
2016-10-15 17:53
---

jonathanlevi
2016-10-15 17:53
So, how can I help? :wink:

jonathanlevi
2016-10-15 17:54
Let’s do this then:

jonathanlevi
2016-10-15 17:54
Fetch and try to build https://gerrit.hyperledger.org/r/#/c/1269 We are talking `Sep 27, 8:17AM`, merged on `Oct 6, 11:52AM`

jonathanlevi
2016-10-15 17:54
Locally on our machines. Maybe this failed too.

ramesh
2016-10-15 18:00
I see this in after executing `make unit-test` on commit # de2cade ```vagrant@hyperledger-devenv:v0.0.11-777bdac:/opt/gopath/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02$ ls chaincode_example02.go chaincode_example02.log chaincode_example02_test.go ```

ramesh
2016-10-15 18:00
there is a log file in example02 directory.. could be because of this..

ramesh
2016-10-15 18:01
re-running again ..

jonathanlevi
2016-10-15 18:01
OK

jonathanlevi
2016-10-15 18:02
We need: 1. To be able to reproduce any CI result locally. 2. To know what commit level does really pass (at all times, regardless how many times we run it) 3. After 2, to identify when the v0.6 branch start failing (what got merged).

jonathanlevi
2016-10-15 18:02
Let’s focus on 2 still. What was the latest build/merge/version of v0.6 that was successful. Sure, let’s re-run.

muralisr
2016-10-15 18:05
@ramesh chaincode_example02.log is wrong

muralisr
2016-10-15 18:05
what in the world is happening :slightly_smiling_face:

ramesh
2016-10-15 18:06
yes that's why chaincode is changing I guess.. but re-running again

muralisr
2016-10-15 18:06
is this in CI or local in your env

muralisr
2016-10-15 18:08
if the CI env has been instrumented to create a log file in chaincode_example02 folder, its going to fail again

ramesh
2016-10-15 18:11

muralisr
2016-10-15 18:20
guys

muralisr
2016-10-15 18:20
one sec please

jonathanlevi
2016-10-15 18:20
OK

muralisr
2016-10-15 18:20
@ramesh `is this in CI or local in your env`

ramesh
2016-10-15 18:21
in my vagrant environment

muralisr
2016-10-15 18:21
forgt that

cbf
2016-10-15 18:22
omg what's going on?

ramesh
2016-10-15 18:22
ok Just now tested in CI environment on commit# 344304b I am able to reproduce this issue


cbf
2016-10-15 18:22
can someone look at commit logs?

muralisr
2016-10-15 18:23
@cbf will do

jonathanlevi
2016-10-15 18:23
Yes, I did.

cbf
2016-10-15 18:23
nothing weird like merge master?

jonathanlevi
2016-10-15 18:23

cbf
2016-10-15 18:25
on my phone because t-rex does it look ok?

jonathanlevi
2016-10-15 18:25

jonathanlevi
2016-10-15 18:26
@cbf ^^^

jonathanlevi
2016-10-15 18:26
That’s the commit history of v0.6

muralisr
2016-10-15 18:28
@jonathanlevi @ramesh reverify of https://gerrit.hyperledger.org/r/#/c/1767/ passed and we don’t see cc-2-cc errors there

jonathanlevi
2016-10-15 18:28
Yup

jonathanlevi
2016-10-15 18:28
That’s the issue: they all fail locally. Succeed on the CI.

jonathanlevi
2016-10-15 18:28
That’s why I was re-running them...

muralisr
2016-10-15 18:29
ok

muralisr
2016-10-15 18:29
in your local env

muralisr
2016-10-15 18:29
can you do an `ls -altr` in the chaincode_example02 folder

muralisr
2016-10-15 18:29
assuming if its still failing for you

ramesh
2016-10-15 18:44
@muralisr : unit-tests failed in CI on commit# 344304b (Fixing a unit test error in cc2cc) with the same error

ramesh
2016-10-15 18:45
but on Commit# de2cade (latest commit on v0.6) I could see unit-tests are working as expected..

muralisr
2016-10-15 18:46
@ramesh what could happen is this

muralisr
2016-10-15 18:46
developer see unit test failing on local

ramesh
2016-10-15 18:46
Executing unit-tests on commit# de2cade in my vagrant environment

muralisr
2016-10-15 18:46
and modify chaincode_example04 to fix it

jzhang
2016-10-15 18:47
@muralisr vagrant@hyperledger-devenv:v0.0.11-0659bfe:/opt/gopath/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02$ ls -altr total 52 drwxr-xr-x 1 vagrant vagrant 578 Oct 3 20:11 .. -rw-r--r-- 1 vagrant vagrant 37795 Oct 10 22:59 chaincode_example02.log -rw-r--r-- 1 vagrant vagrant 2852 Oct 14 17:01 chaincode_example02_test.go -rw-r--r-- 1 vagrant vagrant 5017 Oct 14 17:01 chaincode_example02.go drwxr-xr-x 1 vagrant vagrant 170 Oct 14 17:01 .

muralisr
2016-10-15 18:47
right

muralisr
2016-10-15 18:47
like that

muralisr
2016-10-15 18:47
I wonder what’s causing the log file to show up there

jzhang
2016-10-15 18:48
using the latest v0.6 content, cc2cc test failed locally, which is the reason 1759 was made (thinking it was a hash value problem)

muralisr
2016-10-15 18:48
running the make test in 0.6 to see why this is happening

jzhang
2016-10-15 18:48
which of course had to be reverted with 1767 because on the CI machine the hash value was different

muralisr
2016-10-15 18:48
right

jonathanlevi
2016-10-15 18:48
right

muralisr
2016-10-15 18:48
I can’t help thinking this log file is something new

jonathanlevi
2016-10-15 18:48
@jzhang Different error

muralisr
2016-10-15 18:49
note

muralisr
2016-10-15 18:49
the the time on the log file above

jonathanlevi
2016-10-15 18:49
Yup, it is created as part of the build. I see it too.

jzhang
2016-10-15 18:50
maybe the timestamp in the log file content?

jonathanlevi
2016-10-15 18:50
-rw-r--r-- 1 vagrant vagrant 2852 Oct 14 `17:54` chaincode_example02_test.go -rw-r--r-- 1 vagrant vagrant 7359 Oct 14 `17:54` chaincode_example02.log -rwxr-xr-x 1 vagrant vagrant 14167448 Oct 14 `17:54` chaincode_example02 drwxr-xr-x 1 vagrant vagrant 578 Oct 14 `17:54` .. -rw-r--r-- 1 vagrant vagrant 5017 Oct 15 14:21 chaincode_example02.go drwxr-xr-x 1 vagrant vagrant 204 Oct 15 14:21 .

eabailey
2016-10-15 18:50
has joined #fabric-dev

jzhang
2016-10-15 18:51
if the hash was calculated based on the entire folder, then it’ll be different every time

muralisr
2016-10-15 18:51
here’s likely the problem

muralisr
2016-10-15 18:51
docs/nodeSDK/sample-standalone-app.md: cd /opt/gopath/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 docs/nodeSDK/sample-standalone-app.md: CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=0.0.0.0:7051 ./chaincode_example02 > log 2>&1&

muralisr
2016-10-15 18:52
well sorry.. scratch that

muralisr
2016-10-15 18:52
@jzhang we have been running this test for many months now

muralisr
2016-10-15 18:52
as part of unit test

jonathanlevi
2016-10-15 18:52
Yup

jzhang
2016-10-15 18:52
but i think the problem at hand right now is the crypto package’s go test failure

muralisr
2016-10-15 18:52
so if a log file is created its got to be something recent

muralisr
2016-10-15 18:53
ok

jonathanlevi
2016-10-15 18:53
I think we should focus on what I suggested earlier. Trying to find out WHEN it started failing.

muralisr
2016-10-15 18:53
I think there are many problems

jonathanlevi
2016-10-15 18:53
There were 3 problems. 2 got fixed (overnight) with Jim’s pushes/our merges+ revert.

jonathanlevi
2016-10-15 18:53
Now we end up with the latest one, I believe?

muralisr
2016-10-15 18:54
the one that’s left is the crypto package failure ?

jonathanlevi
2016-10-15 18:54
(with `02` issue)

jonathanlevi
2016-10-15 18:54
The problem that @ramesh posted here (that I can reproduce locally too)

jonathanlevi
2016-10-15 18:54
So did Gari earlier this morning, btw.

muralisr
2016-10-15 18:54
:slightly_smiling_face:

jonathanlevi
2016-10-15 18:54
We can all reproduce locally on our machines….

jonathanlevi
2016-10-15 18:55
… while the CI run is successful.

jonathanlevi
2016-10-15 18:55
But it is recent.

jonathanlevi
2016-10-15 18:55
It must be.

muralisr
2016-10-15 18:56
I’ll debug the “why cc-2-cc” is failing locally

jonathanlevi
2016-10-15 18:56
1. Thank you.

muralisr
2016-10-15 18:56
what other problems are there

ramesh
2016-10-15 18:56
CI run is successful on recent commit but it failed with the same error on one commit (commit #344304b) one commit before latest

jonathanlevi
2016-10-15 18:56
2. And I’m trying earlier commits.

ramesh
2016-10-15 18:56
running latest commitn in my vagrant environment removing log file from 02 directory.

jonathanlevi
2016-10-15 18:57
So @muralisr, while you are working on the latest… I’ll try to find a working build that passes locally for me.

muralisr
2016-10-15 18:57
I bet the problem has to do with this

jonathanlevi
2016-10-15 18:57
@ramesh: fine. Even though I did run a SUPER clean build, and it failed. Even from vagrant destroy.

jzhang
2016-10-15 18:59
i’m also running a clean vagrant freshly built off of v0.6 yesterday


muralisr
2016-10-15 19:00
that’s just a make from 0.6

muralisr
2016-10-15 19:01
well not quite :slightly_smiling_face:

muralisr
2016-10-15 19:01
why is it working for me ?

muralisr
2016-10-15 19:01
it shouldn’t as its failing for you

muralisr
2016-10-15 19:01
let me make sure I refresh everything

jzhang
2016-10-15 19:01
what’s your output “ls -altr”?

muralisr
2016-10-15 19:02
in 02 folder you mean ?

muralisr
2016-10-15 19:02
i expect it to be clean because it worked


jonathanlevi
2016-10-15 19:04
Gents, just another data point...

jonathanlevi
2016-10-15 19:05
I am going back in time and trying earlier builds? Jumped back to

jonathanlevi
2016-10-15 19:05
commit 131b36c9fce40447735fa497e5bdfa8fa3eb3536 Merge: 42ca84b 79589a5 Author: Srinivasan Muralidharan <muralisr@us.ibm.com> Date: Fri Sep 30 11:32:32 2016 +0000 Merge " Java shim build update in DEV mode"

muralisr
2016-10-15 19:05
this is on 0.6 ?

jonathanlevi
2016-10-15 19:05
And it still fails on my machine.

jonathanlevi
2016-10-15 19:05
This is on 0.6

muralisr
2016-10-15 19:06
did you remove *.log and chaincode_example02 exe from the 02 folder ?

jonathanlevi
2016-10-15 19:06
Nope, I’m just getting a clean set of code, in a new branch.

jonathanlevi
2016-10-15 19:06
And running a clean build at a commit-level

muralisr
2016-10-15 19:07
lets do a hangout

muralisr
2016-10-15 19:07
I’ll watch ..so we can debug together

jonathanlevi
2016-10-15 19:07
OK, but I’m warning you. I am using very weird colors in my terminals...

muralisr
2016-10-15 19:07
:slightly_smiling_face:

muralisr
2016-10-15 19:07
I’ll close my eyes


jonathanlevi
2016-10-15 19:08
LOL. Sure. I’m on


cbf
2016-10-15 19:21
how are things going

jonathanlevi
2016-10-15 19:26
We can go back in time and reproduce the failures even from

jonathanlevi
2016-10-15 19:26
commit 131b36c9fce40447735fa497e5bdfa8fa3eb3536 Merge: 42ca84b 79589a5 Author: Srinivasan Muralidharan <muralisr@us.ibm.com> Date: Fri Sep 30 11:32:32 2016

muralisr
2016-10-15 19:28
the core/crypto failed at some level… @jonathanlevi and I are trying to see where the failure started. The cc-2-cc local failures likley a red-herring

jonathanlevi
2016-10-15 19:29
That is, even if we ignore the chaincode 02 failure (by removing the log files) we have some other errors.

jonathanlevi
2016-10-15 19:54
Gari and I are each running a clean, super clean build/test run locally now.

jonathanlevi
2016-10-15 19:54
Murali is doing so too.

cbf
2016-10-15 19:54
guys, go back to v0.6 I bet broken... I suspect we pulled new dependency

jonathanlevi
2016-10-15 19:55
Ramesh had some timeout issue, and he extended and is re-running.

jonathanlevi
2016-10-15 19:55
@cbf, what do you suggest?

cbf
2016-10-15 19:55
try building orig 0.6

jonathanlevi
2016-10-15 19:56
Orig, being?

cbf
2016-10-15 19:56
when we cut the branch

cbf
2016-10-15 19:56
see if same... if broken it is something we are pulling in that isn't pinned

jonathanlevi
2016-10-15 19:57
d9fb219 Re-cut v0.6.0 e5a81bb Create release v0.6.0

cbf
2016-10-15 19:57
sounds right

jonathanlevi
2016-10-15 19:59
OK, let’s do that.

jonathanlevi
2016-10-15 19:59
commit d9fb2195ceb198efe8714a480c6b1afd08694406 Author: Gregory Haskins <gregory.haskins@gmail.com> Date: Thu Sep 15 15:50:04 2016 -0400 Re-cut v0.6.0

jonathanlevi
2016-10-15 20:03
(thank you @ramesh)

ramesh
2016-10-15 20:04
@ramesh uploaded a file: https://hyperledgerproject.slack.com/files/ramesh/F2PRU062G/-.sh and commented: FYI: unit-tests are passed on latest v0.6 commit inside vagrant and CI

jonathanlevi
2016-10-15 20:06
Same for me.

jonathanlevi
2016-10-15 20:06
Just now, from a full, clean build (again)

muralisr
2016-10-15 20:08
yep , I can vouch for it @jonathanlevi … :slightly_smiling_face: so what are the next steps ?

jonathanlevi
2016-10-15 20:11
Let’s build 1607...

jonathanlevi
2016-10-15 20:12
See my latest reverify:

jonathanlevi
2016-10-15 20:12

jonathanlevi
2016-10-15 20:12
It suddenly passes too.

jonathanlevi
2016-10-15 20:13
Shall we merge it then?

jonathanlevi
2016-10-15 20:13
See the 3 previous reverify attempts (of patchset 17 and 18)?

jonathanlevi
2016-10-15 20:14
3 fails + 1 pass. The recent one.

jonathanlevi
2016-10-15 20:14
What has changed. It’s definitely not the case. I did rebase.

muralisr
2016-10-15 20:14
some of the past failures are likely due to the cc-2-cc confusion

muralisr
2016-10-15 20:15
from the past history of checkins to 0.6, I don’t see too much risk … the biggest changes have been to the nodejs SDK

muralisr
2016-10-15 20:16
so I’d say +1 to merge but leave it to you all

jonathanlevi
2016-10-15 20:17
Let’s do it.


cbf
2016-10-15 20:51
so what's up? did some dependency go bad and then good?

jonathanlevi
2016-10-15 20:52
To be honest, I’m not clear.

jonathanlevi
2016-10-15 20:52
It is very strange to have 1607 suddenly passing.

cbf
2016-10-15 20:53
builds are good?

jonathanlevi
2016-10-15 20:53
Gari tried 3+ times using the CI and it failed. My last run succeeded.

cbf
2016-10-15 20:53
we need to do a post mortem... this is weird

jonathanlevi
2016-10-15 20:53
BUT, a few of us also tried a full clean build on our machines and it started passing just two hours ago.

jonathanlevi
2016-10-15 20:54
`cbf [1:53 PM] we need to do a post mortem... this is weird`

jonathanlevi
2016-10-15 20:54
Yes, you can say that one again :wink:. We really ought to.

jonathanlevi
2016-10-15 20:55
Our work plan it to run the 1655 against the latest v0.6 (I have rebased, and it’s running)

jonathanlevi
2016-10-15 20:55
And even if everything is OK, we would still run/test locally.

jonathanlevi
2016-10-15 20:56
For context `1655` is where the JavaScript/integration tests are checked-in for testing the TLS feature in `1607`, all in `v0.6`.

cbf
2016-10-15 20:57
thx

jonathanlevi
2016-10-15 20:58
We are like 4+ people on it. But we’ll get there.

cbf
2016-10-15 21:00
you guys are troopers

cbf
2016-10-15 21:18
0.6 is not on the new base image system is it?

cbf
2016-10-15 21:18
is it still building its own base image etc?

jonathanlevi
2016-10-15 21:23
It uses the 9 days old image I think.

jonathanlevi
2016-10-15 21:23
1607 fails after the merge, btw.

jonathanlevi
2016-10-15 21:24
(the latest v0.6 branch)

jonathanlevi
2016-10-15 21:24
We are re-running. Just a headsup.


ramesh
2016-10-15 22:14
@jonathanlevi unit-tests are executed successfully in CI on latest v0.6 commit


jonathanlevi
2016-10-15 22:15
Yup, I am running them locally too and it looks good here too.

ramesh
2016-10-15 22:15
yes me too

jonathanlevi
2016-10-15 22:15
Next, is to make sure that we are happy with the 1655 patchset

jonathanlevi
2016-10-15 22:15

jonathanlevi
2016-10-15 22:16
(Running the tests again, to make sure)

jonathanlevi
2016-10-15 22:16
Who knows, maybe we will have a `v0.6` release.

jonathanlevi
2016-10-15 22:16
:pray:

jonathanlevi
2016-10-15 22:34
Can others please try out a local build of 1655?

jonathanlevi
2016-10-15 22:34
We are reverifying it as you can see, but I want some more data points at this point.

jonathanlevi
2016-10-15 22:35
@ramesh, @muralisr, @jzhang (after you are done with the latest v0.6), etc.

jonathanlevi
2016-10-15 22:36

ramesh
2016-10-15 22:36
sure I am running latest in my vagrant once done will check out 1655

muralisr
2016-10-15 22:37
trying 1655

jonathanlevi
2016-10-15 22:37
(thanks)

garisingh
2016-10-15 22:38
me too

ramesh
2016-10-15 22:38
seems jenkins slaves went offline.. some network glitch I guess

garisingh
2016-10-15 22:38
`make unit-tests` ?

jonathanlevi
2016-10-15 22:39
@ramesh I’m more worried about CI declaring that things work when they don’t… than the other way around.

jonathanlevi
2016-10-15 22:39
@garisingh: yes, for now. Yes.

jonathanlevi
2016-10-15 22:39
If it’s good, we’ll run the node sdk tests (for checking the TLS fix)

garisingh
2016-10-15 22:40
`make unit-tests` runs both the go tests and sdk tests

garisingh
2016-10-15 22:41
but as it turns out, I ran `make unit-test` anyway so will follow up with the sdk tests :disappointed:

jonathanlevi
2016-10-15 22:54
Yes, so the (in)consistent failures we saw today and last night… pop up already at the `unit test` stage. I think it’s important that we run the full test suite… once we know that at least the Golang tests are consistently passing.

jonathanlevi
2016-10-15 22:54
I’m doing the same (the `unit-test` and then will run the full `unit-tests`)

jonathanlevi
2016-10-15 22:55
Thank G-d it’s raining in SF :wink: and windy and foggy and …

garisingh
2016-10-15 22:55
I'm running `make images` `make unit-test` `make unit-tests`

garisingh
2016-10-15 22:55
I don't really lead too exciting of a life anymore :wink: Plus my wife is out doing something :wink:

jonathanlevi
2016-10-15 22:56
Yeah, exciting life is really over-rated. Running tests manually is the next big thing.

jonathanlevi
2016-10-15 22:57
Wonder what I have been doing in all those other weekends...

muralisr
2016-10-15 22:57
just make it exiting with variations of `vagrant xxx`

garisingh
2016-10-15 22:58
I still never have and never will use vagrant for this project :wink:

muralisr
2016-10-15 22:58
:slightly_smiling_face:

garisingh
2016-10-15 22:58
I am pretty sure when I was younger that I had better things to do. Must have been fun as I don't recall most of my 20's

jonathanlevi
2016-10-15 23:00
BTW: (and I swear I’m not making this up), just opened another terminal and read `make: warning: Clock skew detected. Your build may be incomplete.`

jonathanlevi
2016-10-15 23:00
I think our clocks are really skewed. I don’t remember a huge portion of my 20s.

muralisr
2016-10-15 23:01
ok. that’s hitting below the belt…I don’t reember day before yesterday :slightly_smiling_face:

jonathanlevi
2016-10-15 23:02
"We are as good as our latest patchset”, eh? :wink:

muralisr
2016-10-15 23:05
my recent life has been strictly Markovian :wink:

muralisr
2016-10-15 23:05
started unit-test with 1655

muralisr
2016-10-15 23:18
make unit-test passe

jonathanlevi
2016-10-15 23:19
A full, clean build?

muralisr
2016-10-15 23:19
yes

muralisr
2016-10-15 23:19
from scratch

jonathanlevi
2016-10-15 23:19
From `vagrant destroy`?

jonathanlevi
2016-10-15 23:19
:wink:

muralisr
2016-10-15 23:19
yes

muralisr
2016-10-15 23:19
:slightly_smiling_face:

muralisr
2016-10-15 23:19
not taking chances

jonathanlevi
2016-10-15 23:20
OK. Thanks. Off to node sdk ?

muralisr
2016-10-15 23:20
just do make node-sdk ?

jonathanlevi
2016-10-15 23:21
`make unit-tests` (in plural)

muralisr
2016-10-15 23:22
ok.. had started `make node-sdk-unit-tests`

jonathanlevi
2016-10-15 23:22
Sure thing.

jonathanlevi
2016-10-15 23:22
(yes, yes, I see why you’d do it, etc. ;-))

muralisr
2016-10-15 23:46
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F2PSY3RFT/pasted_image_at_2016_10_15_07_46_pm.png and commented: node unit tests pass in 1655

ramesh
2016-10-15 23:49
unit-test passed in 1655

ramesh
2016-10-15 23:49
running node-sdk now..

jonathanlevi
2016-10-15 23:52
Golang unit-tests passed both me and Gari too.

jonathanlevi
2016-10-15 23:53
Let’s wait for our node sdk tests to finish locally (Jonathan and @ramesh) and if they pass like they pass for Murali… we can continue.

jonathanlevi
2016-10-16 00:07
Sat Oct 15 23:52:43 UTC 2016 UT tests PASSED make[1]: Leaving directory `/hyperledger/sdk/node' vagrant@hyperledger-devenv:v0.0.11-0000118:/hyperledger$ git log --oneline -1 7123f77 xnode-sdk: Test Updates for supporting TLS

jonathanlevi
2016-10-16 00:07
(that is, the node sdk tests PASSED for me)

jonathanlevi
2016-10-16 00:16
---

jonathanlevi
2016-10-16 00:16
We have merged 1655.

ramesh
2016-10-16 00:16
```exit code: 0 Sun Oct 16 00:16:05 UTC 2016 UT tests PASSED make[1]: Leaving directory `/opt/gopath/src/github.com/hyperledger/fabric/sdk/node' vagrant@hyperledger-devenv:v0.0.11-777bdac:/opt/gopath/src/github.com/hyperledger/fabric$ git log --oneline -n 1 7123f77 xnode-sdk: Test Updates for supporting TLS ```

jonathanlevi
2016-10-16 00:16
Noting that it added only node-sdk tests.

ry
2016-10-16 00:16
I have opened a ticket with our provider about the Jenkins issues

ramesh
2016-10-16 00:17
@ry I have opened one [Hyperledger Helpdesk #31550]

ry
2016-10-16 00:17
@ramesh I am Hyperledger Helpdesk

ry
2016-10-16 00:17
:slightly_smiling_face:

ramesh
2016-10-16 00:17
yes yes

jonathanlevi
2016-10-16 00:19
Many thanks @ry. @ramesh, thanks for the confirming the tests passing for you too.

jzhang
2016-10-16 00:50
thanks guys, I couldn’t help with the 1655 verification because I had a strange error that no one else seemed to experience (basically “make unit-test” and the go tests runner tried to look for tests inside sdk/node/node_modules and failed)

jzhang
2016-10-16 00:52
so glad that for the new repo fabric-sdk-node I have decided to 1) remove typescript 2) not rely on vagrant 3) use native host (windows or mac) as dev environment

jzhang
2016-10-16 00:53
so let me pop that question: we can cut v0.6 now right? :wink:

claytonsims
2016-10-16 00:59
deafening silence…….gari what do you think?

cbf
2016-10-16 01:08
@jzhang: yeah, I was working on a fix for that... still unclear why we are seeing that error/warning

garisingh
2016-10-16 01:12
I think we call it a day / night and regroup in the morning. But I think everything is in so that's good

jonathanlevi
2016-10-16 01:18
@claytonsims I think we are ready to cut a release, yes.

jonathanlevi
2016-10-16 01:19
But there is some more work that needs to be done.

jonathanlevi
2016-10-16 01:19
[I might call it a day too. Started (too) early]

claytonsims
2016-10-16 01:19
yoda says ‘do or do not'

claytonsims
2016-10-16 01:20
:slightly_smiling_face:

jonathanlevi
2016-10-16 01:20
:slightly_smiling_face:

yacovm
2016-10-16 08:06
any ETA on when the `feature/convergence` branch will have vendor folders like `master`?

garisingh
2016-10-16 10:23
@yacovm - I believe we are currently trying to merge / move convergence to master? So I imagine once we are there we can vendor new things

ghaskins
2016-10-16 11:45
First step is we are merging master out to convergence

ghaskins
2016-10-16 11:46
We completed the work to resolve conflicts on Friday and are just running the resulting tree through UTs, etc

claytonsims
2016-10-16 20:52
any decision on cutting v6?

yacovm
2016-10-18 08:01
In fabric 0.5, the `core.yaml` file, the `peer.tls.{cert, key} `are needed to be configured in order for p2p to work with SSL. What roles do these files have? Are they the peer's public and private key? If so- what happens is that when a peer starts up it sends the pub key to the membership service in order for the membership service to distribute them to the rest of the peers on demand? @garisingh perhaps you know?

garisingh
2016-10-18 10:16
Hi @yacovm - `peer.tls.{cert, key}` would be what you would normally call the "server" key pair in the web server / app server world - aka used for the server-side TLS endpoint

garisingh
2016-10-18 10:17
The TLS communication today is strictly one-way

yacovm
2016-10-18 10:17
the server-side p2p you mean

yacovm
2016-10-18 10:17
it's 1 way- I know, you have that "initiated chat" bool thing

garisingh
2016-10-18 10:18
one-way TLS - meaning there is no exchange of client certificates at the TLS layer

yacovm
2016-10-18 10:18
oh ok

yacovm
2016-10-18 10:18
But, is it a self signed cert then?

garisingh
2016-10-18 10:19
and basically when you "enroll" with membership services, each peer / client downloads the root CA for the TLSCA - so again trust is at a pure root CA level

garisingh
2016-10-18 10:20
there's a chicken / egg problem actually - so each peer can get its TLS cert from membership services (its part of enrollment) but then there is no way to really configure it to use it dynamically. So you basically would need to start the peer with TLS disabled, enroll the peer, stop the peer, change the config to point to the key/cert pair you just downloaded and then restart with TLS enabled

yacovm
2016-10-18 10:20
but when you call cryptoPeer.Verify and you don't have the certificate of that peer, a gRPC goes to the membership service and downloads something which does into your crypto validator cache. What is that? is that the same `peer.tls.cert` file, only signed by the membership service?

garisingh
2016-10-18 10:20
NET-NET - its not usable today

yacovm
2016-10-18 10:22
I see, so the `peer.tls.{cert, key}` actually originate from the membership service

yacovm
2016-10-18 10:22
what do you mean by NET-NET ?

garisingh
2016-10-18 10:22
"in short"

garisingh
2016-10-18 10:22
or "bottom line"

garisingh
2016-10-18 10:23
for the BMX service - we don't use the TLS certs issued by membership services - we actually use our own

garisingh
2016-10-18 10:24
but we kinda trick the system since we use a wildcard

garisingh
2016-10-18 10:25
the whole thing is a mess because the TLSCA doesn't properly issue TLS certs with the right CNs, Subject or SANs - so hostname verification fails unless you use the override

garisingh
2016-10-18 10:25
which makes it all essentially worthless

yacovm
2016-10-18 10:26
I remember invoking openssl and then trying to start the peer with that, didn't work

yacovm
2016-10-18 10:26
so I used the chaincode folder's certificates :confused:

garisingh
2016-10-18 10:27
So - for v1.0 - my take is that we don't make TLS optional - it should always be used for p2p connections and we do it in a usable / useful fashion. We have most of the core plumbing / building blocks, it's just putting it together correctly

yacovm
2016-10-18 10:27
ok and 1 more question - the crypto peer has this Sign/ verify methods. Are these different from the same files used for the SSL?

garisingh
2016-10-18 10:27
yeah

garisingh
2016-10-18 10:28
there are enrollment certs which are used for signing and TLS certs used for p2p communication

yacovm
2016-10-18 10:28
I see... well there goes that idea, @donovanhide there is no point of playing with the TLS-unique anymore.

yacovm
2016-10-18 10:29
thanks Gari, I understand things better now!

garisingh
2016-10-18 10:29
well I would not necessarily rule that out - in v1.0 I am not sure why one could not use the same cert for signing and TLS

garisingh
2016-10-18 10:29
in the case of peers which have to be identified anyway

yacovm
2016-10-18 10:29
that idea was for 0.5

garisingh
2016-10-18 10:30
0.5 and 0.6 have "sailed" as they say. v1.0 is all we should care about :wink:

yacovm
2016-10-18 10:30
i see

garisingh
2016-10-18 10:31
meaning we can fix bugs on 0.6 but the whole community should be getting behind v1.0

garisingh
2016-10-18 10:31
else we will never get it done

yacovm
2016-10-18 10:32
ok

milansijan
2016-10-18 18:31
has joined #fabric-dev

witwiki
2016-10-20 02:59
has joined #fabric-dev

msoumeit
2016-10-20 15:12
has joined #fabric-dev

yacovm
2016-10-20 22:01
if I submit a PR tomorrow- from which branch should I branch out from? master or convergence?

muralisr
2016-10-20 22:49
@yacovm still some discussion going on in fabric-reconcile

muralisr
2016-10-20 22:49
hopefully soon we will have everything in master …

muralisr
2016-10-20 22:49
can it wait ?

weeds
2016-10-21 01:36
@yacovm I agree would be easier to wait. We are really trying to get the convergence done so the skeleton will be there for people to start adding the other components on.

yacovm
2016-10-21 05:01
Sure

kh2se2013
2016-10-21 13:49
has joined #fabric-dev

jzhang
2016-10-21 19:35
is confidentiality enabled in the current convergence branch on endorsement API? in other words, if I encrypt endorsement payload with the “pkChain” returned from “ECertCreateResp”, the endorser is able to decrypt it right? wondering with the v1.0 how that’s supposed to work, now that with the endorsers role and multi-channel introduced, does a “public key for the chain” still make sense?

jzhang
2016-10-21 19:35
wouldn’t that be a per-channel key pair instead of a common pair for the whole network?

jzhang
2016-10-21 19:54
or, as per @muralisr from #fabric-reconcile channel, this is now left completely to the client and chaincode? is that just going to be merely TLS or would there still be encryption on the payload itself? if the latter, then I think there should be a standard REST API all endorsers publish to download the certificate for extracting the public key for encryption

jzhang
2016-10-21 19:55
ok, will re-post to #fabric-crypto channel as suggested by @muralisr

muralisr
2016-10-21 19:57
ah already did :slightly_smiling_face: but please do add @jzhang

jzhang
2016-10-21 19:57
thanks

thiruworkspace
2016-10-21 21:53
has joined #fabric-dev

zanejia
2016-10-24 06:12
has joined #fabric-dev

yacovm
2016-10-24 09:22
Can anyone explain how this CI failure can happen even though that map is now protected by a RWMutex? https://jenkins.hyperledger.org/job/fabric-verify-x86_64/1955/console

donovanhide
2016-10-24 09:40
@yacovm Try running that single test with the `-race` flag set and it will tell you exactly.

donovanhide
2016-10-24 09:55
```go test -race http://github.com/hyperledger/fabric/core/crypto === Start tests for scenario 'Using crypto_test.yaml properties' === 10:50:08.318 [ca] NewCA -> INFO 001 Fresh start; creating databases, key pairs, and certificates. open socket... open socket...done 10:50:08.374 [aca] Start -> INFO 002 Staring ACA services... 10:50:08.374 [aca] startACAP -> INFO 003 ACA PUBLIC gRPC API server started 10:50:08.374 [aca] Start -> INFO 004 ACA services started ================== WARNING: DATA RACE Read at 0x00c420167b90 by goroutine 13: runtime.mapaccess2_faststr() /usr/local/Cellar/go/1.7.1/libexec/src/runtime/hashmap_fast.go:297 +0x0 http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*moduleLeveled).Log() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/level.go:113 +0x9f http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).log() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:170 +0x34d http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Info() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:239 +0x68 http://github.com/hyperledger/fabric/membersrvc/ca.(*ECA).Start() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/membersrvc/ca/eca.go:192 +0x108 http://github.com/hyperledger/fabric/core/crypto.startPKI() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:1574 +0x24d Previous write at 0x00c420167b90 by goroutine 15: runtime.mapassign1() /usr/local/Cellar/go/1.7.1/libexec/src/runtime/hashmap.go:442 +0x0 http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*moduleLeveled).SetLevel() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/level.go:104 +0x8e http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.SetLevel() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/backend.go:33 +0x70 http://github.com/hyperledger/fabric/core/crypto.TestCryptoInitDoesntOverrideLoggingLevel() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_settings_test.go:35 +0x50 testing.tRunner() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:610 +0xc9 Goroutine 13 (running) created at: http://github.com/hyperledger/fabric/core/crypto.before() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:140 +0x47 http://github.com/hyperledger/fabric/core/crypto.runTestsOnScenario() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:155 +0x234 http://github.com/hyperledger/fabric/core/crypto.TestMain() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:80 +0xf0 main.main() http://github.com/hyperledger/fabric/core/crypto/_test/_testmain.go:124 +0x1b5 Goroutine 15 (running) created at: testing.(*T).Run() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:646 +0x52f testing.RunTests.func1() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:793 +0xb9 testing.tRunner() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:610 +0xc9 testing.RunTests() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:799 +0x4ba testing.(*M).Run() /usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:743 +0x12f http://github.com/hyperledger/fabric/core/crypto.runTestsOnScenario() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:156 +0x245 http://github.com/hyperledger/fabric/core/crypto.TestMain() /Users/donovanhide/gopath/src/github.com/hyperledger/fabric/core/crypto/crypto_test.go:80 +0xf0 main.main() http://github.com/hyperledger/fabric/core/crypto/_test/_testmain.go:124 +0x1b5 ==================```

donovanhide
2016-10-24 09:55
There were other data races found in other parts of the code, so I’d recommend adding the `-race` flag to a unit test pass of the CI process.

yacovm
2016-10-24 09:59
first of all- thanks for the tip. second- I'm not interested in data races of other stuff but only in this specific test because I *thought* I fixed that bug, and even had a test that fails with high probability without the fix, and I ran that test with 10000 goroutines with -race enabled and didn't see a data race :confused: so I'm trying to see if there is some other code path my test doesn't check

donovanhide
2016-10-24 10:01
The above quote shows the race that resulted in the panic in your Jenkins log.

yacovm
2016-10-24 10:02
wait a second.... `fabric/vendor/github.com/op/go-logging/level.go:104` this is a blank line in my IDE and I'm on the master branch. Is it possible the CI server doesn't have the updated vendor folders?

donovanhide
2016-10-24 10:04
Run this locally: `go test -race http://github.com/hyperledger/fabric/core/crypto` and see if you get a race.

yacovm
2016-10-24 10:04
I tried but it outputted too much stuff

donovanhide
2016-10-24 10:04
Did you add a `-v`?

donovanhide
2016-10-24 10:05
Your race is the first one.

yacovm
2016-10-24 10:06
oops. yes

yacovm
2016-10-24 10:07
why did it output level.go:104? that's a blank line

donovanhide
2016-10-24 10:09
I think when the optimisers kick in the line numbering tends to be before the actual optimised function.

yacovm
2016-10-24 10:13
did that crypto test run for a long time on your PC too?

yacovm
2016-10-24 10:13

donovanhide
2016-10-24 10:13
Yes, took a minute or two...

donovanhide
2016-10-24 10:14
`-race` recompiles all dependencies with race detection enabled and then everything runs more slowly. It’s the valgrind of Go :slightly_smiling_face:

yacovm
2016-10-24 10:15
valgrind detects data races too?

donovanhide
2016-10-24 10:15
That’s mostly what I’ve used it for :slightly_smiling_face:

yacovm
2016-10-24 10:16
oh right, ripple is C++

yacovm
2016-10-24 10:17
I think it's stuck

yacovm
2016-10-24 10:17
the test

yacovm
2016-10-24 10:17
yep. it was killed because it ran for too long

donovanhide
2016-10-24 10:17
I’d recommend writing a unit test for your patch to `op/go-logging` that demonstrates the race and fix that first. Maybe you should add that unit test to your PR :slightly_smiling_face:

yacovm
2016-10-24 10:17
Maybe I needed to run the peer before

yacovm
2016-10-24 10:20
@donovanhide , I *have* a unit test, that's the whole problem. I ran it with 100,000 goroutines and it didn't catch fire

yacovm
2016-10-24 10:20
core/utils/utils_test.go , last function

donovanhide
2016-10-24 10:21
It’s not a complete test: https://github.com/yacovm/go-logging/blob/b042c5e48dcf4b2c19b6feea14e7f4b5eaca7ddf/logger_test.go#L64-L75 You need to look at the data race report, and see that you are invoking the Log() method.

donovanhide
2016-10-24 10:22
And also run the test itself with the `-race` flag

donovanhide
2016-10-24 10:24
Also it’s possible that the goroutine finishes before the second loop even begins :slightly_smiling_face: You’d need to synchronise the starting of the two loops and maybe stick some `time.Sleep()` in so that the scheduler gets a chance to kick in. Testing concurrency is hard :slightly_smiling_face:

yacovm
2016-10-24 10:26
well, that's true, but empirically- when I tested it on my machine it failed almost all times without the patch and didn't fail once with the patch so I thought that was good enough

donovanhide
2016-10-24 10:27
Empirically you have evidence above that it does fail :slightly_smiling_face: Anyway, I need to some other work now :wink:

yacovm
2016-10-24 10:27
sure, thanks for the -race tip.

yacovm
2016-10-24 10:47
I don't see the logging data race when I run it locally, weird

weeds
2016-10-24 13:31
I have had a lot of questions in terms of where all the design documentation is for Hyperledger-fabric. Apparently there are people in the community that have problems finding it. As a result, Binh Nguyen created a link in Hyperledger wiki to help. Hopefully this helps everyone: https://wiki.hyperledger.org/community/fabric-design-docs

muralisr
2016-10-24 15:48
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F2TCHE3TN/move_convergence_changeset_to_master.txt and commented: cheat sheet for bringing change sets from convergence to master post merge @ghaskins @ry

jzhang
2016-10-24 19:09
@muralisr @ghaskins I’m getting errors like below when trying to run “docker-compose-next-4.yml” in a freshly rebuilt vagrant (destroy/up) with latest master: vp1_1 | panic: runtime error: invalid memory address or nil pointer dereference vp1_1 | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x710947] vp1_1 | vp1_1 | goroutine 56 [running]: vp1_1 | panic(0xb1d660, 0xc420018070) vp1_1 | /opt/go/src/runtime/panic.go:500 +0x1a1 vp1_1 | http://github.com/hyperledger/fabric/core/peernext.(*Impl).handleChat(0xc4203c26c0, 0x7f83d73ee928, 0xc4200182a0, 0x7f83d73eecb8, 0xc4203f25a0, 0x1, 0x0, 0x0) vp1_1 | /opt/gopath/src/github.com/hyperledger/fabric/core/peernext/peer.go:566 +0x1d7 vp1_1 | http://github.com/hyperledger/fabric/core/peernext.(*Impl).chatWithPeer(0xc4203c26c0, 0xc42000c94d, 0x8, 0x20, 0xc420125a20) vp1_1 | /opt/gopath/src/github.com/hyperledger/fabric/core/peernext/peer.go:553 +0x61b vp1_1 | created by http://github.com/hyperledger/fabric/core/peernext.(*Impl).chatWithSomePeers vp1_1 | /opt/gopath/src/github.com/hyperledger/fabric/core/peernext/peer.go:534 +0x115

jzhang
2016-10-24 19:09
that was vp1, vp0 crashed like below:

jzhang
2016-10-24 19:11
vp0_1 | panic: runtime error: invalid memory address or nil pointer dereference vp0_1 | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x710947] vp0_1 | vp0_1 | goroutine 16 [running]: vp0_1 | panic(0xb1d660, 0xc420018070) vp0_1 | /opt/go/src/runtime/panic.go:500 +0x1a1 vp0_1 | http://github.com/hyperledger/fabric/core/peernext.(*Impl).handleChat(0xc4203b03c0, 0x7f1a5303cd78, 0xc420155830, 0x7f1a530772b0, 0xc4203db120, 0x421500, 0x0, 0x0) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/core/peernext/peer.go:566 +0x1d7 vp0_1 | http://github.com/hyperledger/fabric/core/peernext.(*Impl).Chat(0xc4203b03c0, 0x115bdc0, 0xc4203db120, 0xc42001e4a8, 0xc42001e4d0) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/core/peernext/peer.go:258 +0xa8 vp0_1 | http://github.com/hyperledger/fabric/protos._Peer_Chat_Handler(0xbc8da0, 0xc4203b03c0, 0x115a500, 0xc42009dd00, 0xc420155830, 0x0) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/protos/fabric.pb.go:696 +0xbb vp0_1 | http://github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC(0xc4201d0bd0, 0x115b520, 0xc42007c2d0, 0xc42008c3c0, 0xc4203ad290, 0x113db80, 0xc420155800, 0x0, 0x0) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:657 +0x6f3 vp0_1 | http://github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4201d0bd0, 0x115b520, 0xc42007c2d0, 0xc42008c3c0, 0xc420155800) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:741 +0xc33 vp0_1 | http://github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc4203db070, 0xc4201d0bd0, 0x115b520, 0xc42007c2d0, 0xc42008c3c0) vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:402 +0xab vp0_1 | created by http://github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1 vp0_1 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:403 +0xa3

muralisr
2016-10-24 19:39
@jzhang will have to look but the only thing that has been tested to work is the simple skeletong with CLI

muralisr
2016-10-24 19:39
was talking with @jeffgarratt about this infact

jeffgarratt
2016-10-24 19:40
@jzhang working on this right now

jeffgarratt
2016-10-24 19:40
putting in a default engine which will remedy this issue

yacovm
2016-10-25 12:58
Hey, question- is there a need for a membership service to run if I want to use the node SDK without security, and if the validator is running in dev mode?

weeds
2016-10-25 16:48
For Hyperledger-fabric, a few of us are trying to put what we are working on over the next month in the JIRA boards based off of the requirements for the roadmap that are tracked in Jira by end of day Tuesday: https://jira.hyperledger.org/issues/?filter=-2&jql=ORDER%20BY%20createdDate%20DESC

weeds
2016-10-25 16:49
Jira boards show a prioritized order of items to be implemented based on feedback received, so I would like to encourage the community to take a look at the JIRA boards in case you have comments. Please note that as we work through coding, there is learning, so the boards to shift as part of being an agile team.

weeds
2016-10-25 16:50
if you do have comments- I suggest going to the different slack channels associated with the Jira board. (for example if you want to comment on work for nodejs.sdk- go to fabric-sdk-nod-dev channel)

weeds
2016-10-25 16:52
Also if you have items you are working in these areas as well, please add them to the boards as it would be helpful to understand what others are working on if not already identified. Or if you need help- tag items with "help wanted"

weeds
2016-10-25 16:54
Mark Parzygnat also shared this document on using Jira to understand current work items. This document has been created to give further insight into the work in progress towards the hyperledger/fabric v1 architecture based off the community roadmap. The requirements for the roadmap are being tracked in Jira: https://jira.hyperledger.org/issues/?filter=-2&jql=ORDER%20BY%20createdDate%20DESC It was determined to organize in sprints to better track and show a prioritized order of items to be implemented based on feedback received. We’ve done this via boards. To see these boards and the priorities click on Boards->manage boards: Now on the left side of the screen click on “All Boards”: On this page you will see all the public (and restricted) boards that have been created. If you want to see the currently focused work, click on the boards with “Visibility” = “All Users” and “Board type” = “Scrum” for example Consensus: When you click on Consensus under “Board name” you will be directed to a page that contains the following columns: The meanings to these columns are as follows: • Backlog – list of items slated for the current sprint (sprints are defined in 2 week iterations), but are not currently in progress • In progress – are items currently being worked by someone in the community. • In Review – waiting to be reviewed and merged in Gerritt • Done – merged and complete in the sprint. If you want to see all items in the backlog for a given feature set click on the stacked rows on the left navigation of the screen: This shows you items slated for the current sprint at the top, and all items in the backlog at the bottom. Items are listed in priority order. If there is an item you are interested in working on, want more information or have questions, or if there is an item that you feel needs to be in higher priority, please add comments directly to the Jira item. All feedback and help is very much appreciated.

senthil
2016-10-25 18:48
has joined #fabric-dev

kostas
2016-10-25 18:58
Do we know whether *CI* now runs on Go 1.7?

ry
2016-10-25 19:22
kostas no it doesn't

ry
2016-10-25 19:22
that was something ghaskins was working on with muralisr IIRC

kostas
2016-10-25 19:30
@ry: Thanks for the update. I remember @ghaskins giving me a heads up on this, just wanted to check on its progress.

ry
2016-10-25 19:34
kostas if you can wait until tomorrow I may have a solution

ry
2016-10-25 19:35
kostas my hair is on fire right now, though, so... not today

kostas
2016-10-25 19:52
@ry: No problem at all, thank you. Post an update here whenever it's done if you can, and I'll enable the Go 1.7-related tests.

donovanhide
2016-10-25 20:22
Anyone had issues with the building of chaincode being incredibly slow? ```19:43:58.136 [consensus/pbft] ProcessEvent -> INFO 027 Replica 0 batch timer expired 19:43:58.136 [consensus/pbft] sendBatch -> INFO 028 Creating batch with 1 requests 19:43:58.373 [consensus/pbft] executeOne -> INFO 029 Replica 0 executing/committing request batch for view=0/seqNo=1 and digest HjKuvhOoO7kuwpNAUDLpRuLIi/zLmBJr2xvZENIbzDlzFVYS4hRTZVLGH8P0U+qaXe+CWx6n068bhEwtvzVfew== 20:11:30.383 [consensus/pbft] execDoneSync -> INFO 02a Replica 0 finished execution 1, trying next``` It’s taken 28ish minutes to do the first part of the docker image build! I’m running 5 peers on 3x3.75GB Google Cloud boxes. Must be doing something wrong :slightly_smiling_face:

garisingh
2016-10-25 20:52
@donovanhide - are you sharing one Docker daemon across all the peers? Or is each peer on a separate hosts with its own local daemon?

donovanhide
2016-10-25 20:56
Each peer has its own matching docker daemon running in another container.

garisingh
2016-10-25 20:56
on the same host?

donovanhide
2016-10-25 20:56
peer-1,docker-1,peer-2,docker-2,etc.

garisingh
2016-10-25 20:56
are you using DinD ?

donovanhide
2016-10-25 20:56
Yep.

donovanhide
2016-10-25 20:58
```... containers: - name: docker image: docker:dind securityContext: privileged: true ports: - containerPort: 2375 name: docker - name: peer image: hyperledger/fabric-peer:latest command: ["sh","-c","sleep 10;CORE_PEER_ID=$(hostname|sed 's/peer-/vp/') CORE_PEER_ADDRESS=$(hostname).peer.default.svc.cluster.local:7051 peer node start"] env: ….```

garisingh
2016-10-25 20:59
When I used DinD, a couple of times I noticed that it was taking forever to download the fabric-baseimage (which is the base for each chaincode container)

donovanhide
2016-10-25 21:00
Yeah, if I shutdown the cluster, I get a sudden rush of half-downloaded image logs...

donovanhide
2016-10-25 21:00
Think DinD is a dead-end?

garisingh
2016-10-25 21:03
It was working pretty well for me. What I ended up doing was building a wrapper image around docker:dind where I ran a script on startup to do a "docker pull" and "docker tag" to get the base image preloaded on startup before trying to deploy chaincode

donovanhide
2016-10-25 21:03
I can try and replicate that :slightly_smiling_face:

donovanhide
2016-10-25 21:04
Wonder why it is slow though?

garisingh
2016-10-25 21:04
I honestly never figure it out. it only happen sometimes

donovanhide
2016-10-25 21:05
Is it not tempting to actually send the docker image over GRPC as part of the protocol? Build once, use everywhere?

garisingh
2016-10-25 21:05
the first time I used DinD it worked like a charm. Then it started flaking when pulling and building so I preloaded the baseimage

garisingh
2016-10-25 21:05
technically you could do what you mention

donovanhide
2016-10-25 21:06
Currently?

garisingh
2016-10-25 21:07
so basically what you are sending over GRPC is a Docker tar.gz file like you would send to the Docker remote API

garisingh
2016-10-25 21:08
so you could pretty much create a Docker tarball with a Dockerfile that was "from scratch and a statically compiled chaincode binary"

garisingh
2016-10-25 21:09
if you take a look through the NodeJS SDK, you'll actually see the point where we build this tarball using a hardcoded Dockerfile

garisingh
2016-10-25 21:09
which takes the chaincode src, etc

garisingh
2016-10-25 21:10
you could replace that part and build the tarball the way I mentioned above and call the same GRPC API

donovanhide
2016-10-25 21:10
Interesting! Sounds like I should get my hands dirty with some go GRPC invocations :slightly_smiling_face: Thanks!

garisingh
2016-10-25 21:11
I knew that would get you revved up! (see how I did that :wink: )

donovanhide
2016-10-25 21:11
You did :slightly_smiling_face: I also told you I’d break things :wink:

garisingh
2016-10-25 21:11
touche!

ry
2016-10-25 21:35
I recall an issue where someone was not running it in an empty directory or something and the DinD image was growing to an unbound size as it tried to make an image of itself

donovanhide
2016-10-25 21:55
@ry any links to more detail?

ry
2016-10-25 21:57
donovanhide no, this was an issue at the hackfest in Amsterdam. If you're seeing your DinD image growing unbound and never launching, look into that. @cbf knows the details.

donovanhide
2016-10-25 21:58
Ok, thanks, sounds like it might be the issue!

ry
2016-10-25 21:59
it's like the first step or something in the directions and this guy ran it in his home directory or something like that.

conghonglei
2016-10-26 00:31
has joined #fabric-dev

baohua
2016-10-26 07:59
i noticed that the sprint2 of jira is in complete status now, many related tasks are gone at the board. Anyone know how to create new sprint or project at jira? Thanks!

oiakovlev
2016-10-26 08:50
has joined #fabric-dev

harrisob
2016-10-26 14:20
has joined #fabric-dev

harrisob
2016-10-26 14:24
I see a new directory called ‘next’ under /protos , should we start using these ?

cbf
2016-10-26 23:26
@baohua: there should be a button to create a new one

baohua
2016-10-27 01:55
Thanks @cbf, however, the button does not allow to create new project or sprint. Maybe some owner of the JIRA board can help? Thanks!

ry
2016-10-27 01:56
baohua can you tell me exactly what you need?

baohua
2016-10-27 01:58
yes, ry. Previously we use the sprint2 to collect the related task on the fabric-sdk-py project. However, now sprint2 is marked as complete, then we cannot find a single place for the collection. Maybe I’m not using jira in the correct method? Thanks for any advice


ry
2016-10-27 02:00
so do you need a Sprint 4 for SDK-py or something?

ry
2016-10-27 02:02
I've never really used this feature in Jira. If you need something, I'll create it for you, I'm just not sure exactly what you need

baohua
2016-10-27 02:05
Yes, sprint 4 will not expire soon, right? Then please help create one, thanks for your help!

ry
2016-10-27 02:06
what do you want it called?

ry
2016-10-27 02:07
are you locked with fabric release?

baohua
2016-10-27 02:14
SDK-Python should be good, and we will target at release 1.0, thanks!


ry
2016-10-27 02:33
that's the pythonSDK board, so what you need is a new sprint there?

ry
2016-10-27 02:33
I just created sprint 4 there, you should see it and be able to move issues there

baohua
2016-10-27 02:33
yes, this is good, but can it show a board with processing status, like which is in todo, which is in processsing...

ry
2016-10-27 02:34
can you show me an example of what you want in another project?

ry
2016-10-27 02:34
I think by creating the new sprint you can drag items from the backlog

ry
2016-10-27 02:35
if you refresh this page: https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=85&view=planning.nodetail are you able to drag items from the backlog and reorder them?

baohua
2016-10-27 02:36
yes, i’m dragging :slightly_smiling_face: let me find an example

baohua
2016-10-27 02:37
can we let them shown at here, in active sprint view: https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=85

jzhang
2016-10-27 04:03
@binhn @muralisr have we decided on the “endorsement policy” design? in earlier discussions we said it’ll be up to the application code to inspect endorsement inside ProposalResponse and judge on whether criteria have been met. is that still the case? I see “endorsement policy” mentioned lately that seems to point to an official construct expressing that criteria. can you please clarify?

nitin
2016-10-27 09:31
has joined #fabric-dev

zxc
2016-10-27 09:50
has joined #fabric-dev

muralisr
2016-10-27 12:17
@jzhang `it’ll be up to the application code to inspect endorsement inside ProposalResponse and judge on whether criteria have been met. is that still the case` … I think so. I remember we also talked about how the application can just get ProposalResponse from the first Endorser and pass that to others so other endorsers can use that in addition to the endorsement policy. We should revisit this to see if we still want to do this and if so, go over the details

garisingh
2016-10-27 14:32
its more like a pre-check though - as VSCC will actually enforce endorsement policy as well as MVCC

garisingh
2016-10-27 14:32
so the app is not the sole gatekeeper

garisingh
2016-10-27 14:33
but you would build the thing responsible for obtaining, packaging and submitting endorsed transactions using the client sdk(s)

muralisr
2016-10-27 14:41
`pre-check` is a good way to think about this, agreed…. perhaps a good time to point at the VSCC angle (verify signatures etc) as in this https://jira.hyperledger.org/browse/FAB-187

jzhang
2016-10-27 15:12
@muralisr @garisingh makes sense, and “endorsement policy” on the VSCC side is also to be implemented with pure code right? in other words we are not defining a “endorsement policy” construct to _declaratively_ express “at least 1 valid signature”, “must be signed by these specific identities”, “80% or more approved and signed” or other custom policies right?

muralisr
2016-10-27 15:17
@jzhang `Explicit list of signatures; advanced implementation may allow boolean expressions including AND, OR. For example, (a AND b) OR c` is best done declaratively… if done in go , users will be forced to implement VSCC for every policy which is not just a usability issue but may also have code bloat and performance. Note that the `(a AND b) OR c` is just a convenience representation…. it could be JSON (@jyellick suggestion.) This could be part of the support in his dsl.

muralisr
2016-10-27 15:18
if we do this right this could be a powerful feature… but need @binhn @garisingh input/signoff

jzhang
2016-10-27 15:19
"this could be a powerful feature” - yes agreed, but will this be done by March considering all the work in other areas? it feels like a nice to have feature but not critical

muralisr
2016-10-27 15:21
I think this is not hard to do…. ? when the dust settles down, its these kind of usability features that determine user buy-in. Just IMO again… you could be 100% right

jyellick
2016-10-27 15:26
@muralisr I would stress that JSON is a nice CLI input, because it's human readable, but, internally I would always store as bytes (so we can leverage the protobuf niceness)

muralisr
2016-10-27 15:27
@jyellick undoubtedly

muralisr
2016-10-27 15:33
@jzhang one more thing to consider. … with this declarative approach, modifying the policy is just a transaction. Users won’t have to install a new VSCC and rebuild

weeds
2016-10-27 16:29
For awareness- Binh created a link pointing to the design documentation. Gossip was added most recently- https://wiki.hyperledger.org/community/fabric-design-docs

bmos299
2016-10-27 19:40
has joined #fabric-dev

yacovm
2016-10-27 21:36
Who is Tim S?

harrisob
2016-10-28 18:28
Hello … just rebuilt from fabric/master Trying to run a deploy proposal and getting on the peer side … however the response back to NodeSDK is status 200 @jeffgarratt @murali.surampalli 19:32:24.053 [chaincode] processStream -> ERRO 0c9 Error handling chaincode support stream: stream error: code = 1 desc = "context canceled"

arthur.yu
2016-10-29 03:08
has joined #fabric-dev

frankwg
2016-10-31 03:23
has joined #fabric-dev

rickr
2016-10-31 23:58
has joined #fabric-dev

jhamhader
2016-11-01 08:40
has joined #fabric-dev

pluradj
2016-11-01 13:35
has joined #fabric-dev

adc
2016-11-01 14:06
It looks like there is failure when running 'make all': recipe for target 'linter' failed. I have posted a JIRA issue here: https://jira.hyperledger.org/browse/FAB-920. Anyone knowing why it is failing?

ghaskins
2016-11-01 14:10
@adc: there are similar reports, looking into it

ghaskins
2016-11-01 14:11
Not clear why, but the linter is acting non deterministic

ghaskins
2016-11-01 14:12
I think generally the issues are legit, just not clear why some runs pass

yacovm
2016-11-01 14:12
maybe the linter version is different in the CI and on some of the envs?

ghaskins
2016-11-01 14:12
We've seen it in other contexts

yacovm
2016-11-01 14:12
ok

ghaskins
2016-11-01 14:13
Short answer, we should probably fix any found as a superset

rickr
2016-11-01 14:13
I reported the errors it shows .. I don't have the GO experience to know if they're a concern or not.

adc
2016-11-01 14:14
in my case, it reports that solo/broadcast.go and solo/broadcast_test.go contain errors

yacovm
2016-11-01 14:14
someone needs to open a PR to google or whoever makes the linter/vet, so it'll have a -w flag that can fix simple cases like these, where you have a single value in the struct

harrisob
2016-11-01 15:12
How do I do chaincode query ? When doing an invoke we set the first arg to be the function name ‘invoke’, however when setting it to ‘query’, the invoke is being called on the chaincode not the query. How do we build the proposal request to do a query?

rangao
2016-11-01 16:21
has joined #fabric-dev

jzhang
2016-11-01 17:52
@muralisr @jeffgarratt @binhn with the new .proto files checked into master, how much of the new APIs and grpc message formats are completed? I tried to look inside bddtests for reference of a client impl but didn’t see any targeting the new APIs

jzhang
2016-11-01 17:52
when “make behave” only a few solo and kafka orderer tests ran, others are skipped or failed

jzhang
2016-11-01 18:08
I’m getting some hint on impl details in fabric/protos/util/proputils.go, but would be nice if the bddtests are caught up with the peer

ermyas
2016-11-01 22:41
has joined #fabric-dev

michaelwang
2016-11-02 07:33
has joined #fabric-dev

bryan-huang
2016-11-02 10:12
Hi all, I got some problem to unmarshal transaction payload and chaincode id from the block event, when the transaction’s ConfidentialityLevel = 1, I should get a privatekey to decrypt it, so the question is privatekey owner, who is the owner, it is the member that issued the transaction, right ? thank a lot.

bryan-huang
2016-11-02 10:50
Got the answer, thanks again

rickr
2016-11-02 11:49
Hi If I want to tag my images before a build to move back do I need to also include the *env and src container images ?

stevenroose
2016-11-02 12:06
has joined #fabric-dev

stevenroose
2016-11-02 12:08
Hi, I'm new to Gerrit and Jira. I made a change to the chaincode shim package and tried to submit it to Gerrit. (It was a branch with two commits and it created two separate items for it, but that's not too bad, they make separate changes). Do I also have to do something on the Jira side in order to get people to review the change?

ghaskins
2016-11-02 12:39
hello @stevenroose…if you pushed the CRs to gerrit, you dont need to do anything else in particular…I know I regularly scan the list and review whats there (though I am woefully behind on account of travel last week).

ghaskins
2016-11-02 12:40
@rickr not sure what you mean….the docker images already are tagged with $arch-$version

ghaskins
2016-11-02 12:40
you shouldnt need any more than that, I would think

ghaskins
2016-11-02 12:40
but perhaps I am misunderstanding

rickr
2016-11-02 12:40
I thought the clean-dist would remove them all

rickr
2016-11-02 12:41
I do that before the build -- maybe I don't need to do that ..

ghaskins
2016-11-02 12:46
generally, I wouldnt use that unless you are really wanting to sanitize

rickr
2016-11-02 12:51
I've been bit too many may times in the past with left overs corrupting builds :slightly_smiling_face:

ghaskins
2016-11-02 13:07
understood...though if that occurs I would like to know about it

ghaskins
2016-11-02 13:07
at the very least, you probably want "make clean" not "dist-clean", as that nukes tools and stuff like that

ghaskins
2016-11-02 13:07
but even that shouldnt be strictly necessary

rickr
2016-11-02 13:16
speaking of which .. just got latest master fresh clone ... built in vagrant (fresh too) ... seeing ... ``` ok http://github.com/hyperledger/fabric/gossip/comm 33.118s coverage: 85.6% of statements ok http://github.com/hyperledger/fabric/gossip/discovery 21.125s coverage: 70.4% of statements 2016/11/02 13:09:38 WARNING (*connection).serviceInput():(comm-5612)[Closing reading from stream] 2016/11/02 13:09:38 WARNING (*connection).serviceInput():(comm-5610)[Closing reading from stream] 2016/11/02 13:09:38 WARNING (*connection).readFromStream():(comm-5613)[[108 111 99 97 108 104 111 115 116 58 53 54 49 48 (lots more) ] canceling read because closing] 2016/11/02 13:09:38 WARNING (*connection).readFromStream():(comm-5615)[[108 111 99 97 108 104 111 115 116 58 53 54 49 51] canceling read because closing] 2016/11/02 13:09:38 WARNING (*connection).serviceInput():(comm-5611)[Closing reading from stream] Took 7.103924487s http://github.com/hyperledger/fabric/gossip/gossip.getGoroutineRawText(0x7f09e0, 0xacd530) /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:552 +0x79 http://github.com/hyperledger/fabric/gossip/gossip.getGoRoutines(0x1dcd6500, 0xc420190540, 0x89d716) /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:558 +0x56 http://github.com/hyperledger/fabric/gossip/gossip.ensureGoroutineExit(0xc420190540) /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:508 +0x3b8 http://github.com/hyperledger/fabric/gossip/gossip.TestPull(0xc420190540) /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:227 +0x946 testing.tRunner(0xc420190540, 0x8cbf20) /opt/go/src/testing/testing.go:610 +0x81 created by testing.(*T).Run /opt/go/src/testing/testing.go:646 +0x2ec testing.(*T).Run(0xc420190240, 0x891c59, 0x8, 0x8cbf20, 0xc42013fc01) /opt/go/src/testing/testing.go:647 +0x316 testing.RunTests.func1(0xc420190240) /opt/go/src/testing/testing.go:793 +0x6d testing.tRunner(0xc420190240, 0xc4205b3d98) /opt/go/src/testing/testing.go:610 +0x81 testing.RunTests(0x8cc730, 0xaa9780, 0xe, 0xe, 0x4109ee) /opt/go/src/testing/testing.go:799 +0x2f5 testing.(*M).Run(0xc4205b3ef8, 0x8a4e7f) /opt/go/src/testing/testing.go:743 +0x85 main.main() http://github.com/hyperledger/fabric/gossip/gossip/_test/_testmain.go:132 +0x1bd runtime.goexit() /opt/go/src/runtime/asm_amd64.s:2086 +0x1 time.Sleep(0x9502f9000) /opt/go/src/runtime/time.go:59 +0xe1 http://github.com/hyperledger/fabric/gossip/gossip.waitForTestCompletion(0xc420011028, 0x9502f9000, 0xc420190540) /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:529 +0x2f created by http://github.com/hyperledger/fabric/gossip/gossip.TestPull /opt/gopath/src/github.com/hyperledger/fabric/gossip/gossip/gossip_test.go:157 +0x141 --- FAIL: TestPull (12.67s) Error Trace: gossip_test.go:506 gossip_test.go:227 Error: Goroutine(s) haven't ended: %s Messages: [testing.(*T).Run(0xc420190240, 0x891c59, 0x8, 0x8cbf20, 0xc42013fc01) /opt/go/src/testing/testing.go:647 +0x316 testing.RunTests.func1(0xc420190240) /opt/go/src/testing/testing.go:793 +0x6d testing.tRunner(0xc420190240, 0xc4205b3d98) /opt/go/src/testing/testing.go:610 +0x81 testing.RunTests(0x8cc730, 0xaa9780, 0xe, 0xe, 0x4109ee) /opt/go/src/testing/testing.go:799 +0x2f5 testing.(*M).Run(0xc4205b3ef8, 0x8a4e7f) /opt/go/src/testing/testing.go:743 +0x85 main.main() http://github.com/hyperledger/fabric/gossip/gossip/_test/_testmain.go:132 +0x1bd] 20 ``` 898ea6e0add33ec998a09eadc7aa32c989fffa00

yacovm
2016-11-02 13:33
you have a Mac right? @rickr

garisingh
2016-11-02 16:06
@yacovm - even the latest patch you submitted was failing on my Mac

garisingh
2016-11-02 16:06
discovery tests worked but gossip failed

garisingh
2016-11-02 16:07
oops - will pull down latest patch set

rickr
2016-11-02 16:10
@yacovm no building on linux

yacovm
2016-11-02 16:10
you're buliding on linux?! How is that possible you have a different stack trace structure in your tests than both my PC and the CI server? :confused:

yacovm
2016-11-02 16:10
anyway- I made a PR that should fix that bug

yacovm
2016-11-02 16:11
can you test it locally?

yacovm
2016-11-02 16:11
you just need to replace 1 function :slightly_smiling_face:

rickr
2016-11-02 16:12
not urgent I can get the sdk to do what I need. I just feel I should report if I'm seeing errors like that

garisingh
2016-11-02 16:12
@yacovm - still fails for me on a Mac

yacovm
2016-11-02 16:12
I'll be grateful if you can simply replace 1 function in your code and re-run the test

rickr
2016-11-02 16:13
post it .. I'll see if I can

yacovm
2016-11-02 16:14

yacovm
2016-11-02 16:14
in: `gossip/gossip/gossip_test.go`

rickr
2016-11-02 16:32
@yacovm yup ran clean now

yacovm
2016-11-02 16:32
great, thanks! can you just re-run please?

yacovm
2016-11-02 16:32
just to make sure

yacovm
2016-11-02 16:32
and tell also how much time did it take?

rickr
2016-11-02 16:33
no cpu or disk io metrics ?

yacovm
2016-11-02 16:33
no i just want time

rickr
2016-11-02 16:33
how long do you expect it to be ?

yacovm
2016-11-02 16:38
like 2 min

rickr
2016-11-02 16:41
wow you have some mac 7m36.968s

yacovm
2016-11-02 16:43
I don't have a Mac

yacovm
2016-11-02 16:43
I have a windows machine and I'm running intellij on an ubuntu VM

rickr
2016-11-02 16:43
You can do whole suite in 2min ?

yacovm
2016-11-02 16:43
less...

yacovm
2016-11-02 16:44
it takes 100 seconds on the CI server and also on my machine

rickr
2016-11-02 16:45
I can't imagine that hardware can really cut it down that much .. can't be OS

yacovm
2016-11-02 16:48
I also don't know why it is acting this way... it runs very fast on CI and on my machine.

yacovm
2016-11-02 16:56
now I tweaked the tests and I managed to make then run in 1m 17s

yacovm
2016-11-02 17:59
Now in CI I managed to reduce it to: `17:58:58 ok http://github.com/hyperledger/fabric/gossip/gossip 82.007s coverage: 94.0% of statements`

jzhang
2016-11-03 04:45
@jyellick @jeffgarratt @muralisr I need your help figuring out how to make transactions work with the new protos, using protos/util/proputil.go as reference, I have the following code in node.js test case, trying to build a valid Transaction2 object using ProposalResponse: let headerExt = new _ccProposalProto.ChaincodeHeaderExtension(); let header = new _headerProto.Header(); header.setType(_headerProto.Header.Type.CHAINCODE); header.setExtensions(headerExt.toBuffer()); let respPayload = _prProto.ProposalResponsePayload.decode(response.payload); let prPayload = new _prProto.ProposalResponsePayload(); prPayload.setProposalHash(respPayload.proposalHash); prPayload.setExtension(respPayload.extension); let ccaPayload = new _ccTxProto.ChaincodeActionPayload(); ccaPayload.setChaincodeProposalPayload(Buffer.from([])); // “Buffer.from([])”, also tried “payload” field in the response from the endorser ccaPayload.setAction({ proposalResponsePayload: prPayload.toBuffer(), endorsements: [response.endorsement] }); let tx = new _txProto.Transaction2(); tx.setActions([{ header:header.toBuffer(), payload: ccaPayload.toBuffer() }]); and getting the following status in the response from the orderer: BAD_REQUEST

muralisr
2016-11-03 13:08
@jzhang there is a known issue in orderer (will be fixed when rest of the protos stuff is in … @jyellick to chime in/correct)

muralisr
2016-11-03 13:09
the workaround is

muralisr
2016-11-03 13:09
```func createBroadcastRuleset(configManager configtx.Manager) *broadcastfilter.RuleSet { return broadcastfilter.NewRuleSet([]broadcastfilter.Rule{ broadcastfilter.EmptyRejectRule, configfilter.New(configManager), broadcastfilter.AcceptRule, }) }``` in orderer/main.go …. comment out `configfilter.New(configManager),` for now and see if it works ?

jzhang
2016-11-03 13:10
haha, i’m just debugging that and realizing that the configRule inside the broadcastServer was causing the Reject

muralisr
2016-11-03 13:10
:slightly_smiling_face:


jzhang
2016-11-03 13:10
thanks I’ll give it a try

muralisr
2016-11-03 13:11
sure, let me know if that doesn’t work...

jzhang
2016-11-03 13:14
@muralisr that hack got me past it

jzhang
2016-11-03 13:14
is there a bug opened for that?

muralisr
2016-11-03 13:17
not yet @jzhang …feel free to open and assign to @jyellick


jzhang
2016-11-03 13:21
@jyellick ^^^ thanks!

jzhang
2016-11-03 13:21
@muralisr thanks man for getting my unstuck!

jzhang
2016-11-03 13:22
now need to figure out if I built the transaction object properly to be taken by the committer :wink:

jzhang
2016-11-03 13:26
@dave.enyeart so the following log message says the transaction was valid and committed to the ledger right? vp0_1 | 13:24:57.104 [lockbasedtxmgmt] validateTx -> DEBU 3ee Validating txRWSet:lccc::ReadSet~18chaincodes-default:1,18chaincodes-default64d93257dac2560fe52d7a62d8aacb150ac1a5f5ede2d7f6dca710f13aae1bfa9b:0,WriteSet~18chaincodes-default64d93257dac2560fe52d7a62d8aacb150ac1a5f5ede2d7f6dca710f13aae1bfa9b=[[]byte{0xa, 0x42, 0xa, 0x40, 0x64, 0x39, 0x33, 0x32, 0x35, 0x37, 0x64, 0x61, 0x63, 0x32, 0x35, 0x36, 0x30, 0x66, 0x65, 0x35, 0x32, 0x64, 0x37, 0x61, 0x36, 0x32, 0x64, 0x38, 0x61, 0x61, 0x63, 0x62, 0x31, 0x35, 0x30, 0x61, 0x63, 0x31, 0x61, 0x35, 0x66, 0x35, 0x65, 0x64, 0x65, 0x32, 0x64, 0x37, 0x66, 0x36, 0x64, 0x63, 0x61, 0x37, 0x31, 0x30, 0x66, 0x31, 0x33, 0x61, 0x61, 0x65, 0x31, 0x62, 0x66, 0x61, 0x39, 0x62, 0xa, 0x2, 0x10, 0x0, 0xa, 0xd5, 0xe, 0x32, 0xd2, 0xe, 0xa, 0x5e, 0x8, 0x1, 0x12, 0x42, 0x12, 0x40, 0x64, 0x39, 0x33, 0x32, 0x35, 0x37, 0x64, 0x61, 0x63, 0x32, 0x35, 0x36, 0x30, 0x66, 0x65, 0x35, 0x32, 0x64, 0x37, 0x61, 0x36, 0x32, 0x64, 0x38, 0x61, 0x61, 0x63, 0x62, 0x31, 0x35, 0x30, 0x61, 0x63, 0x31, 0x61, 0x35, 0x66, 0x35, 0x65, 0x64, 0x65, 0x32, 0x64, 0x37, 0x66, 0x36, 0x64, 0x63, 0x61, 0x37, 0x31, 0x30, 0x66, 0x31, 0x33, 0x61, 0x61, 0x65, 0x31, 0x62, 0x66, 0x61, 0x39, 0x62, 0x1a, 0x16, 0xa, 0x4, 0x69, 0x6e, 0x69, 0x74, 0xa, 0x1, 0x61, 0xa, 0x3, 0x31, 0x30, 0x30, 0xa, 0x1, 0x62, 0xa, 0x3, 0x32, 0x30, 0x30, 0x1a, 0xef, 0xd, 0x1f, 0x8b, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3, 0xed, 0x58, 0x6d, 0x73, 0xda, 0x38, 0x10, 0xee, 0x57, 0xf4, 0x2b, 0xf6, 0x3c, 0xd7, 0xe, 0xf4, 0xa8, 0x79, 0x27, 0xd7, 0xdc, 0xe4, 0x83, 0x49, 0xd2, 0x96, 0x69, 0xf, 0x72, 0x90, 0x5e, 0xd2, 0x9, 0x99, 0x8c, 0xb0, 0x65, 0xf0, 0x5, 0x6c, 0x2a, 0xc9, 0x10, 0xae, 0xd3, 0xff, 0x7e, 0x2b, 0xc9, 0x80, 0x43, 0x42, 0xda, 0xb4, 0x49, 0x7b, 0xbd, 0x8b, 0x66, 0x1a, 0x61, 0xaf, 0xb4, 0x7a, 0xf6, 0xed, 0x59, 0xb9, 0xf6, 0xa3, 0xfb, 0x1f, 0xc5, 0x62, 0x71, 0xab, 0x56, 0x3, 0x3d, 0xd7, 0xcd, 0x5c, 0x2c, 0x57, 0xcd, 0x9c, 0xc, 0x28, 0x55, 0x8a, 0xc5, 0x7a, 0xbd, 0x52, 0x2b, 0x97, 0xaa, 0x80, 0xcb, 0x2a, 0x95, 0x32, 0x3c, 0xaa, 0x7d, 0x3, 0x6c, 0x8f, 0x62, 0x21, 0x29, 0x47, 0x28, 0x5f, 0... vp0_1 | 13:24:57.105 [kvledger] Commit -> DEBU 3ef Committing block to storage vp0_1 | 13:24:57.105 [protos] ConstructSerBlock2 -> DEBU 3f0 ConstructSerBlock2():TxOffsets=[]int{1, 4254} vp0_1 | Commit success, created a block! vp0_1 | 13:24:57.110 [kvledger] indexBlock -> DEBU 3f1 Indexing block [blockNum=3, blockHash=[]byte{0x9c, 0x4d, 0xb, 0xf0, 0x80, 0x2a, 0x2c, 0x23, 0x44, 0x4c, 0xd0, 0xa9, 0xa4, 0x79, 0xa0, 0x11, 0x30, 0xfb, 0xbb, 0x6c, 0xd7, 0x86, 0xa5, 0x8e, 0xa4, 0xe3, 0x7f, 0xaa, 0xda, 0x56, 0x53, 0x65, 0x57, 0x80, 0xff, 0x51, 0xe8, 0x83, 0x7a, 0xb, 0xc7, 0x60, 0x7f, 0x52, 0xa9, 0x56, 0x2e, 0x1, 0x15, 0x70, 0x36, 0xd8, 0x71, 0x31, 0xd4, 0x15, 0x6c, 0xc3, 0xba, 0x25, 0x32, 0x21, 0xd6, 0x77}] vp0_1 | 13:24:57.110 [kvledger] indexBlock -> DEBU 3f2 Adding txLoc [fileSuffixNum=0, offset=4354, bytesLength=4253] for tx [3:0] to index vp0_1 | 13:24:57.110 [kvledger] updateCheckpoint -> DEBU 3f3 Broadcasting about update checkpointInfo: latestFileChunkSuffixNum=[0], latestFileChunksize=[8613], lastBlockNumber=[3] vp0_1 | 13:24:57.110 [kvledger] Commit -> DEBU 3f4 Committing block to state database

dave.enyeart
2016-11-03 13:28
yes, that shows the chaincode deploy is indeed getting written to ledger

jzhang
2016-11-03 15:41
@jyellick @muralisr regarding https://jira.hyperledger.org/browse/FAB-939, what needs to happen for this error to get resolved? Jason you said "Once the fabric transitions onto the new transaction format”, is that work that Muarli needs to do? will this impact the SDK?

jzhang
2016-11-03 15:42
see https://gerrit.hyperledger.org/r/#/c/2219/ for what I did in node.js to get things to work in the latest fabric (with the hack of commenting out configFilter)

jyellick
2016-11-03 15:48
@jzhang This is work that is currently underway. Maybe I can briefly summarize. The fabric transaction format was developed with the needs of the fabric in mind, but not with the needs of the orderer (which has much simpler requirements). So, we attempted to pare down the usage of the fabric transaction to be what the orderer understood, but it ended up being a doomed endeavor. Instead, it was decided to build the absolute simplest signed message format to use with the orderer, and then rework the fabric transaction on top of this new structure. Ultimately, the `Envelope` messages will be the outer structure encoded into the block, and encapsulating the fabric transactions. There's a plan in place, but I can't speak to its status, @muralisr or @adc might be better equipped to do so.

jyellick
2016-11-03 15:49
But this leaves us in the position today where the fabric expects `Transaction2` type messages and the orderer expects `Envelope` messages. Which is causing the bug you are seeing.

jzhang
2016-11-03 15:51
thanks Jason for the details. makes sense.

jzhang
2016-11-03 15:51
so what’s the plan in the meantime to unblock squads that are dependent on the orderer service allowing the Transaction2 format through?

jzhang
2016-11-03 15:51
does it make sense to add a temporary hack?

jyellick
2016-11-03 15:52
@muralisr and I had discussed this, told him I was happy to accommodate that, but he said it was easy enough for him to add the local hack (which he screenshotted you I believe)

jzhang
2016-11-03 15:53
you mean commenting out the configFilter rule as I did above?

jzhang
2016-11-03 15:54
that’d be OK by me if there are no other ramifications :wink:

jyellick
2016-11-03 15:54
Ah, your screenshot, my mistake. But yes, unless you are interested in testing reconfiguration, commenting out that line should be benign

jzhang
2016-11-03 15:55
make sense. i can submit a changeset for that. will add you and Murali as reviewer, who else should review it?

jyellick
2016-11-03 15:56
I can

jyellick
2016-11-03 15:56
If you submit, @muralisr and I can each +2 and you should be good to go


jyellick
2016-11-03 16:02
Done

muralisr
2016-11-03 16:02
thanks @jzhang … I was hoping we’d have checked in the protos consolidation work so we won’t need this hack.

muralisr
2016-11-03 16:03
I’ll +2 and submit as soon as the CI passes

jzhang
2016-11-03 16:03
@muralisr even if this temp fix lived for just one day it’s useful

muralisr
2016-11-03 16:03
agreed

muralisr
2016-11-03 16:03
I meant we were hoping to get the consolidation in sooner….its getting delayed

jyellick
2016-11-03 16:05
@muralisr Do you know the division of who is working on what? I got sidetracked moving the ab related protos to the main dir yesterday, was thinking to do that today, unless you think I'll be stepping on toes

muralisr
2016-11-03 16:08
right…give me a few minutes

muralisr
2016-11-03 16:12
(on call with daughter… )

jyellick
2016-11-03 16:19
Definitely more important, take your time

muralisr
2016-11-03 16:30
sorry back

muralisr
2016-11-03 16:35
@jyellick `moving the ab related protos to the main dir` … I think please do that… only thing not sure how we are going to resolve is collisions with Block ?

muralisr
2016-11-03 16:35
there’s already Block and Block2

jyellick
2016-11-03 16:35
Well, the proto import path will be different

muralisr
2016-11-03 16:35
ok

muralisr
2016-11-03 16:35
so just move the protos ?

jyellick
2016-11-03 16:35
Assuming we like `protos/common` `protos/orderer` and `protos/peer`

muralisr
2016-11-03 16:35
and we will hook up implemetnation with ledger folks ?

muralisr
2016-11-03 16:36
I see

jyellick
2016-11-03 16:36
I would assume that the ledger folks can add an import for `protos/common` and then do `cb.Block` locally

muralisr
2016-11-03 16:36
you’ll do _some_ of the implementation fix to fix up paths

jyellick
2016-11-03 16:36
Right

muralisr
2016-11-03 16:37
sounds great to me...

muralisr
2016-11-03 16:37
perhaps check with others

muralisr
2016-11-03 16:37
?

jyellick
2016-11-03 16:37
@dave.enyeart @manish-sethi Does this work for you?

muralisr
2016-11-03 16:38
I think sooner we all take the same protos the better … then we’ll know what we are bumping against (missing fields etc)

jyellick
2016-11-03 16:41
It will also make the end to end flow much less hacky and real, which I like

manish-sethi
2016-11-03 16:44
@jyellick - yes that works.

manish-sethi
2016-11-03 16:45
Further, I was looking at the changes required in the ledger and would like to understand from you what do you plan for serialization of Block ?

manish-sethi
2016-11-03 16:46
As of now that's what appears to be biggest dependency of ledger.. in addition to importing new path

jyellick
2016-11-03 16:49
I think @adc or @muralisr need to finish the fabric transaction proto changes on top of the new `Envelope` thing

manish-sethi
2016-11-03 16:49
The current Block2 is serialized in a custom manner.... It contains initial bytes for previous hash + tx1bytes + tx2bytes +... TxnBytes+txoffsetinfoBytes+a fixed length footer.

manish-sethi
2016-11-03 16:50
OK, till the serialzation is decided, it will not be possible to make changes in the ledger code.

adc
2016-11-03 16:52
@jyellick but how do you reccomend to proceed? Using directly the envelope or something like the following:


adc
2016-11-03 16:53
which is essentially the structure you have just with different names more transaction oriented

jyellick
2016-11-03 16:54
At the end of the day, what the fabric transaction looks like won't really affect me, so long as the thing that encapsulates it is an `Envelope`. I'd be inclined to utilize the `Envelope` structure to reduce as much duplication as you can though

jyellick
2016-11-03 16:55
I thought the idea had been to utilize the envelope header concatenated with some inner header as the sort overall proposalaction header

jyellick
2016-11-03 16:55
As it nicely makes explicit that the creator is the same for everything

manish-sethi
2016-11-03 16:55
@murali - We are fine with any serialization but the objective is to be able to get the txoffsets from the block bytes we receive at ledger so as to be able to index the tx related offsets by txID

manish-sethi
2016-11-03 16:56
@muralisr I made a mistake while referring to your id ^^^^

adc
2016-11-03 16:58
@jyellick I was hoping to have singed transaction and transaction mapping directly to envelope and payload message that you have in such a way to have a unified transaction concept

jyellick
2016-11-03 16:59
I had posted this to #fabric-crypto earlier this week tagging you and @muralisr and @binhn as to what this outer thing should be called. The only votes were really from @muralisr and @binhn for the `Envelope`/`Payload`/`Header` so that is what I finalized things on

adc
2016-11-03 16:59
for the proposal I have something like this:


adc
2016-11-03 16:59
ah, okay, sorry for that

adc
2016-11-03 17:00
it is easy to remap to that

jyellick
2016-11-03 17:01
No problem, I had just assumed you didn't have a strong opinion on the names so were abstaining. I know the churn is obnoxious for those building changesets on top of these changes, but if you can talk @binhn and @muralisr into changing their minds, we can always rename them again.

adc
2016-11-03 17:02
nono, it's fine

adc
2016-11-03 17:02
I had just missed those messages, sorry :disappointed:

jyellick
2016-11-03 17:03
Perfectly understandable, seems like I have spent 70% of my days typing on slack lately (instead of coding as I would prefer) so it is easy to miss these things as they scroll away

jyellick
2016-11-03 17:04
So you can rework the fabric transaction on top of the `Envelope` and friends protos as defined? My plan is to move them to `protos/common` so that you can call `import` in your fabric protos and utilize those structures so they are shared.

jyellick
2016-11-03 17:04
@manish-sethi The offsets for the transactions do not have to have some fixed rule, correct? They can be computed and stored for each block? (I'm not sure how else this would be accomplished, but just checking)

manish-sethi
2016-11-03 17:07
yes, in current code, last portion of the block (offsetInfo) contains the offsets of the transactions in the block and last 4 bytes of the block store the beginning offset of the offsetInfo.

jyellick
2016-11-03 17:11
Okay, sounds like there should be no problem

muralisr
2016-11-03 17:12
is this summary and understanding correct ?

muralisr
2016-11-03 17:12
(1) Organize protos like @jyellick suggested above into `protos/common`, `protos/peer` and `protos/orderer`… basically collect and organize protos from different packages under protos/… (2) Block2 in common would be replaced with ab.Block (i.e., ab.Block would be renamed to common.Block2) (3) we need to make sure Serialization of the new Block2 is done correctly per @manish-sethi

muralisr
2016-11-03 17:13
are there other crypto related changes @adc @aso ?

aso
2016-11-03 17:14
has joined #fabric-dev

manish-sethi
2016-11-03 17:14
sounds good to me... inviting @dave.enyeart here for his reference...

manish-sethi
2016-11-03 17:33
@jyellick, @muralisr - if you want to serialize in a simple manner e.g., len(tx1Bytes)+tx1Bytes+len(tx2Bytes)+tx2Bytes+.... instead of putting the offsets at the end of the block - even that should also be fine by us.

jyellick
2016-11-03 17:36
@manish-sethi Serialization format doesn't particularly matter to me, would defer to whatever format you want. We do need to decide on how to compute the `BlockData` hash and the `BlockHeader` hash. For now I'm using naive (and theoretically incorrect) straight proto marshaling. The data should probably be done as a wide Merkle tree, and the header should probably be some simple custom marshaling

manish-sethi
2016-11-03 17:37
I would prefer hash on simple custom serialized tx data for performance reasons...

manish-sethi
2016-11-03 17:39
close to what you are doing now... I do not think that this is incorrect. It's just that I am not sure whether we have a use case like bitcoin (where they have thin clients) for doing it Merkle-tree based

jyellick
2016-11-03 17:40
There were several comments in support of the Merkle tree approach

jyellick
2016-11-03 17:41
And if it is a wide Merkle tree, I would expect the performance to be relatively similar to a single large hash

jyellick
2016-11-03 17:41
And there are performance reasons at the orderer why the Merkle tree approach is superior

muralisr
2016-11-03 17:42
@manish-sethi @jyellick for the first pass it’ll be good to make changes that are not too disruptive to ledger ?

jyellick
2016-11-03 17:42
I'm slightly uncertain why the ledger even needs to compute this hash? Only valid blocks should make it into the ledger. The only time would be verifying the hash chain.

muralisr
2016-11-03 17:43
(I’m making the assumption - perhaps unwarranted - that we are trying to go beyond the immediate here… )

manish-sethi
2016-11-03 17:43
@jyellick - If you have done measurements for supporting this and convinced I am fine... but I have doubts based on my previous experiments

jyellick
2016-11-03 17:43
@manish-sethi Real test are still a TODO, agreed with @muralisr this doesn't have to be finalized at the moment, I just wanted to outline it as a TODO

jyellick
2016-11-03 17:44
We should do the real tests before committing

manish-sethi
2016-11-03 17:45
sure @jyellick - don't get me wrong. I was just sharing my intuitions based on some experiments that I had done for crypto-hash computation of entire state in v0.5

jyellick
2016-11-03 17:48
Understood. I am not married to the Merkle tree idea, if it's not better, let's not do it. Are we certain we will never want 'light' nodes which prune some transactions out?

manish-sethi
2016-11-03 17:49
At least I am not certain either way..

jyellick
2016-11-03 17:51
Would also ask @cca if he had other thoughts, as I recall him being a proponent of the Merkle tree

vdods
2016-11-03 18:58
has joined #fabric-dev

vdods
2016-11-03 20:17
Is the v0.6 branch the basis for the hyperledger/fabric-peer:x86_64-0.6.1-preview and hyperledger/fabric-membersrvc:x86_64-0.6.1-preview images that are published on docker hub?

vdods
2016-11-03 20:20
Sorry, I just saw the tags for those -- the answer is no: it's based on the git tag v0.6.1-preview

rickr
2016-11-03 20:24
Today endorsement is done by the Peer service. Could in the future these be implemented by two separate services ? endorsement by one svc and deploy invoke by another. ?

ghaskins
2016-11-03 20:25
@vdods v0.6.1-preview tag is the correct answer, but there is a correlation

ghaskins
2016-11-03 20:25
(e.g. v0.6.1-preview and v0.6.0-preview are both tags from the v0.6 branch

vdods
2016-11-03 20:28
@ghaskins Thanks -- is it necessary to checkout v0.6 branch before resetting to one of those tags? Or is `git reset --hard v0.6.1-preview` sufficient?

ghaskins
2016-11-03 20:29
theres probably a dozen ways to do it in git: the one you provided should work fine as long as you understand the consequences

ghaskins
2016-11-03 20:29
a safer alternative is to perhaps do “git checkout v0.6.1-preview"

garisingh
2016-11-04 00:08
@jyellick @manish-sethi joining this late but I think we should anticipate that there may be valid cases for light clients

sheehan
2016-11-04 01:04
"based on some experiments that I had done for crypto-hash computation of entire state in v0.5" maybe I'm wrong, but based on the conversation I assumed that the "wide merkle" was just over the transactions in a block, not the entire state. @manish-sethi we previously discussed having an array of all transactions hashes in a block which would be used to calculate the block hash. That would allow you to prune the transaction content. I believe that would be somewhat similar to a "wide merkle" until you hit some large number of TX

sheehan
2016-11-04 01:05
I also think it could potentially be used for privacy in the future in addition to pruning

manish-sethi
2016-11-04 05:09
@sheehan - long time :slightly_smiling_face: yes the conversation is about computing hash over the transactions. I was referring to my experiments from a general perspective, where I had observed that the cost of hash computation function is not a linear to the size of the data. It involves a significant setup cost that is incurred each time you invoke this function. For instance, on my Mac, the hash computation took almost the same time for any number of bytes < 100 and there after it starts showing effect based on data volume. I heard once from z folks that for them this number is even larger. So, minimizing the number of times you call the hash function is desired (off course - unless required by some concrete functionality/use case - like a bitcoin thin client wants to verify whether a tx is present in a Block. Further, I believe these bit coin thin clients could be large in number and hence potentially the primary use case). The only thing I was saying that we should have some measurements and use cases we would need to support in order to make a judicious decision.

cca
2016-11-04 08:55
i'm not in context here, but for merkle trees: in a textbook they are always binary. in practice, a wide tree, k-ary for k=32, 64, ... performs much better, as @manish-sethi says. the cost of hash function calculation is not linear in the hashed data, there is a significant setup cost. if the general block format should hold multiple tx, then i recommend at least a merkle tree over the tx, with a configurable k (width) in the code (not modifiable after deployment) ... because there have been quite some discussions on how large the blocks should be in this field!

james
2016-11-04 16:15
has joined #fabric-dev

matt.shams
2016-11-04 19:59
has joined #fabric-dev

sheehan
2016-11-05 03:34
@manish-sethi - I need to find more time to hang out here :slightly_smiling_face: Completely agree with your suggestion to take measurements and evaluate use cases. I think we’re all in agreement though that a wide merkle tree really won’t take that much extra hashing. I’m assuming the system already needs to hash each individual transaction for other purposes so I’m not factoring that into the cost. And that leaves room in the future (if it’s made configurable as Christian suggests) to potentially support a binary merkle tree if someone has lite client with limited space but needs to verify a TX use case.

hiepnm
2016-11-07 10:19
has joined #fabric-dev

hiepnm
2016-11-07 10:22
I have some dummy questions: What is local ledger? What is it different with shared ledger? When I read 3.2.1.3 NonHashData section, I met localLedgerCommitTimestamp field. So I'm curious about it

jzhang
2016-11-07 20:00
@muralisr is the ESCC and VSCC part ready in the peer for the SDK squads to build APIs on top of it?

jzhang
2016-11-07 20:03
@muralisr @binhn @jyellick @kostas I chatted with Kostas about the channel/subledger work, and was told that some of the calls are stub’ed out, but some are working for real, he pointed me to this story https://jira.hyperledger.org/browse/FAB-819, but it looks like it’s only getting started. so here’s my question: 1) what’s the overall status of this work, and 2) would it be smart for the SDK squad to start working on building APIs on top of it?

jyellick
2016-11-07 20:06
1) I would say that APIs are nearly final (hopefully last proto related commit will be merged later today), but implementation support may not be ready for some period of time (@kostas can speak better to this). 2) If the SDK wants to start building APIs, I think that may be okay, with the caveat that they will have nothing to test them against until the implementation is ready

jzhang
2016-11-07 20:12
thanks @jyellick , that helps a lot

muralisr
2016-11-07 20:14
@jzhang regarding ESCC and VSCC .. the ESCC part is being worked on by @aso in https://gerrit.hyperledger.org/r/#/c/2135

binhn
2016-11-07 20:15
jim, are you looking to start sdk on multichannel?

jzhang
2016-11-07 20:15
@binhn yeah was trying to decide if i should start on that in this sprint or not

binhn
2016-11-07 20:15
it is not ready and probably not until end of the month, but maybe we should stub out grpc apis

binhn
2016-11-07 20:16
i think next sprint would be best

jzhang
2016-11-07 20:16
@binhn based on what Jason and Kostas tell me the grpc APIs are almost done being stub’ed out

binhn
2016-11-07 20:16
you also need them on the peer side, which hasn’t been started

binhn
2016-11-07 20:21
maybe you can start as the peer will use a system chaincode to join the channel, so it’s a transaction proposal api

jzhang
2016-11-07 20:21
yep, that’s my understanding as well

binhn
2016-11-07 20:21
the proto has the chainID defined now

kostas
2016-11-07 20:22
@jzhang Right, everything that I talked about is from the orderer side of things. (So, when I talked about validation logic being there, I wasn't referring to ESCC and VSCC but to the signature validation DSL and policy manager.)

jzhang
2016-11-07 20:22
but was thinking that we could start the API design without being able to test it with a backend, still we’ll be able to write unit tests against the params etc.

yacovm
2016-11-08 09:02
what is `kvledger`?

yacovm
2016-11-08 09:02
`fabric/core/ledger/kvledger`

garisingh
2016-11-08 09:11
@yacovm - it's the new state store for v1 - there are 2 implementations - one for RocksDB (moving to goleveldb soon) and one experimental one which used couchdb

yacovm
2016-11-08 09:12
thanks

hiepnm
2016-11-08 09:34
@garisingh what is different between stateCF and stateDeltaCF?

dave.enyeart
2016-11-08 12:19
@hiepnm CF means RocksDB column families, think of them as data partitions within the database. stateCF is world state and stateDeltaCF are the changes in state from a certain point in time. These are 0.5/0.6 implementations and are not in v1.

rickr
2016-11-08 14:26
Hi Just updated to latest in master branch unit test run but : ddtests(master)]$ docker-compose -f docker-compose-next-1.yml up vp0_1 | 14:24:53.266 [nodeCmd] serve -> CRIT 0bc Failed creating new peer with handler Security helper not provided ``` running outside of vagrant

hiepnm
2016-11-09 01:29
@dave.enyeart Thank you! When will version 1.0 release?

dave.enyeart
2016-11-09 01:38
@hiepnm v1.0 is currently targeted for March

hiepnm
2016-11-09 01:47
@dave.enyeart I'm looking forward it

jov
2016-11-09 10:42
has joined #fabric-dev

pd93
2016-11-09 11:13
has joined #fabric-dev

harrisob
2016-11-09 16:28
@binhn @muralisr @jzhang

harrisob
2016-11-09 16:28
Should the ProposalResponse.Response2.status and ProposalResponse.Response2.payload also be signed and have the ProposalResponse.Response2 include a new signature or could it be part of the Endorsement.signature ? How can we trust the status or payload otherwise ?

jzhang
2016-11-09 16:31
unless there are other ways to obtain the query results from the chaincode inside the ProposalResponse, we currently rely on the “Response2.payload” to carry the return value of the chaincode, using this mechanism for “queryByChaincode()”

jzhang
2016-11-09 16:32
to Bret’s questions above, should we care if the Response2.payload is not signed?

jzhang
2016-11-09 16:32
guess it can be protected by TLS (as is “status”)

jzhang
2016-11-09 16:33
but since it’s presumably used by applications to obtain official information on the ledger, I would think it should be signed

muralisr
2016-11-09 16:36
one thing (and @binhn brought this up) … should the “return value” from the CC be saved on the ledger ? if so we cannot set it in Response2.Payload

muralisr
2016-11-09 16:38
on the other hand, that means we are treating all queries as transactions… and there’ll be a lot of them

muralisr
2016-11-09 16:39
what does everyone think ?

jzhang
2016-11-09 16:39
to me i don’t think it makes sense to record queries as transactions

jzhang
2016-11-09 16:40
but the return values of the queries do need to be signed in my opinion

muralisr
2016-11-09 16:42
@jzhang I think so too...

ghaskins
2016-11-09 22:06
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F30NK3KPX/-.sh and commented: @jyellick

ghaskins
2016-11-09 22:06
im seeing this on HEAD

ghaskins
2016-11-09 22:06
expected?

jyellick
2016-11-09 22:07
Yes, let me get the CR


ghaskins
2016-11-09 22:07
ah, haha...i shot too low for @muralisr

ghaskins
2016-11-09 22:07
off by one

ghaskins
2016-11-09 22:08
did you have any thoughts about the v2 thing?

ghaskins
2016-11-09 22:08
was that expected?

jyellick
2016-11-09 22:08
Was about to check that now...

ghaskins
2016-11-09 22:08
if so, its a +2 from me

ghaskins
2016-11-09 22:08
I might just be confused, but I thought that was a sign of a incongruence in the protoc-gen-go you used

jyellick
2016-11-09 22:11
Right, I'm really not sure why, but re-ran `make protos` and I saw an update for that file, not sure how that slipped by last time

ghaskins
2016-11-09 22:11
I got one too, though not in that regard

ghaskins
2016-11-09 22:12
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F2ZUQ5Q2C/-.js and commented: mine looked more like this (there were more hunks than this though)

jyellick
2016-11-09 22:13
And it's still wrong....

ghaskins
2016-11-09 22:13
anyway, this is good, i can now test the docker-based form of this

ghaskins
2016-11-09 22:13
at least I know what will happen on master and can compare it

jyellick
2016-11-09 22:14
I delete `$GOPATH/bin/protoc-gen-go`, then run `make protos` and `protoc-gen-go` is back in my `$GOPATH/bin` and resolves from there under `which protoc-gen-go`

ghaskins
2016-11-09 22:14
one thing that is tripping people up is the fact that $GOPATH/bin/protoc-gen-go is treated gingerly

ghaskins
2016-11-09 22:15
yeah, you might be impacted by the same phenomenon I just eluded to

ghaskins
2016-11-09 22:15
fwiw, this will "go away" in the new design since the tooling is embedded in the docker flow

ghaskins
2016-11-09 22:15
but for now, i think that is the work around

ghaskins
2016-11-09 22:16
theres a delicate balance between being "right" and "not annoying" with makefile deps

ghaskins
2016-11-09 22:17
i think I swung too far to the right on this one

jyellick
2016-11-09 22:17
What is the workaround? I'm still getting the `const _ = proto.ProtoPackageIsVersion2 // please upgrade the proto package` after deleting and regenerating

ghaskins
2016-11-09 22:17
its not picking up when the binary needs to get rebuilt properly

ghaskins
2016-11-09 22:17
oh..hmm

jyellick
2016-11-09 22:17
(Same output from vagrant and my local env)

ghaskins
2016-11-09 22:17
that might just be right then

ghaskins
2016-11-09 22:18
yeah, i might just be confused that "..IsVersion2" == bad

ghaskins
2016-11-09 22:18
i thought someone ran into that in the past that it meant you had protobuf v2.x instead of the expected v3

ghaskins
2016-11-09 22:18
but I might be confused

ghaskins
2016-11-09 22:18
I think it was @yacovm

ghaskins
2016-11-09 22:18
any thoughts on that @yacovm ?

jyellick
2016-11-09 22:18
``` grep -r '// please upgrade the proto package' . | wc -l 49 ```

ghaskins
2016-11-09 22:19
long story short, if you blow away $GOPATH/bin/protoc-gen-go and re-run, it _should_ be generating that fresh from your vendor folder

ghaskins
2016-11-09 22:19
actually that is something to check

ghaskins
2016-11-09 22:20
make sure its actually taking whats in fabric.git/vendor/.../protobuf

ghaskins
2016-11-09 22:20
but I suspect it is

yacovm
2016-11-09 22:20
Was me

ghaskins
2016-11-09 22:20
if in doubt, blow away ./gotools/build and try again

yacovm
2016-11-09 22:20
Override the path

yacovm
2016-11-09 22:21
Go to the vendor folder

yacovm
2016-11-09 22:21
Compile the protoc gem go

yacovm
2016-11-09 22:21
And make jt first in the path

yacovm
2016-11-09 22:22
Thats assuming you want to use the vendors buikd

ghaskins
2016-11-09 22:22
we do

ghaskins
2016-11-09 22:22
though I think in the latest code, this shouldnt be necessary per se...we now move the vendor stuff into ./build rather than $GOPATH/src

ghaskins
2016-11-09 22:22
I think in earlier revs, we were putting stuff in $GOPATH/[src,bin] and that had the potential to get stale

ghaskins
2016-11-09 22:23
but that shouldnt be the case any more

jyellick
2016-11-09 22:25
``` $ export PATH=$PWD/gotools/build/gopath/bin:$PATH && rm -Rf gotools/build && make protos && grep -r '// please upgrade the proto package' . | wc -l .... 49 ```

jyellick
2016-11-09 22:26
@yacovm When you build the protos do you get the `// please upgrade the proto package` comment in your output `pb.go` files?

yacovm
2016-11-09 22:26
You need to compile

yacovm
2016-11-09 22:26
The protocgen go

jyellick
2016-11-09 22:27
``` [yellickj@jmobile fabric]$ export PATH=$PWD/gotools/build/gopath/bin:$PATH && rm -Rf gotools/build && make protos && grep -r '// please upgrade the proto package' . | wc -l mkdir -p build/bin cd gotools && make install BINDIR=/home/yellickj/go/bin make[1]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/golang/lint/golint -> golint make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/kardianos/govendor -> govendor make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://golang.org/x/tools/cmd/goimports -> goimports make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/golang/protobuf/protoc-gen-go -> protoc-gen-go make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/onsi/ginkgo/ginkgo -> ginkgo make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/axw/gocov/... -> gocov make[2]: Leaving directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' make[2]: Entering directory '/home/yellickj/go/src/github.com/hyperledger/fabric/gotools' Building http://github.com/AlekSi/gocov-xml -> gocov-xml ... 49 ```

yacovm
2016-11-09 22:27
No no

yacovm
2016-11-09 22:27
Go to the cendor folder

yacovm
2016-11-09 22:27
Where the protoc gen go is located

yacovm
2016-11-09 22:28
And go build -o protoc-gen-go it

yacovm
2016-11-09 22:28
Sorry i'm on the phone on the bed :sweat_smile:

yacovm
2016-11-09 22:28
Hard to type

ghaskins
2016-11-09 22:28
i assume you mean as a sanity check

yacovm
2016-11-09 22:28
No

ghaskins
2016-11-09 22:28
(the build should be doing this for you)

yacovm
2016-11-09 22:28
Ibdid bot

yacovm
2016-11-09 22:28
Oh really?

ghaskins
2016-11-09 22:28
yes

yacovm
2016-11-09 22:29
Since whwn

yacovm
2016-11-09 22:29
When

ghaskins
2016-11-09 22:29
long long time

ghaskins
2016-11-09 22:29
6+ months, I dont remember exactly

yacovm
2016-11-09 22:29
Huh? You sure?

ghaskins
2016-11-09 22:29
yeah...i wrote it :wink:

yacovm
2016-11-09 22:29
It build the binary in the vendor folder?

ghaskins
2016-11-09 22:29
"make protos" should generate the protoc-gen-go

yacovm
2016-11-09 22:29
Ok

yacovm
2016-11-09 22:30
Hmmmm well thats what i was doing. By the way:

ghaskins
2016-11-09 22:30
though as I was saying earlier, the current one checked into master has a suboptimal behavor w.r.t. detecting stale image

yacovm
2016-11-09 22:30
The compilatiom error is because the pb go file generated doesnt fit the vendor version

yacovm
2016-11-09 22:31
And protoc doesnt know to use vendor

jyellick
2016-11-09 22:31
@yacovm Followed your instructions, produced that `protoc-gen-go` file in the vendor file, then copied it into the `gotools/build/gopath/bin` and my `$GOPATH/bin` dirs, re-ran `make protos`, and still same output.

ghaskins
2016-11-09 22:31
but if the protoc-gen-go came from vendor, this shouldnt happen, right?

yacovm
2016-11-09 22:32
Try not coying it

yacovm
2016-11-09 22:32
Leave it there

yacovm
2016-11-09 22:32
And overridethe path

yacovm
2016-11-09 22:32
I know i know

yacovm
2016-11-09 22:32
Sounds voodo

jyellick
2016-11-09 22:33
Still the same output

jyellick
2016-11-09 22:33
(though the make may be screwing with my path)

yacovm
2016-11-09 22:33
Jyellic also try to do ls -lrt on the file compiled and after you make protos

yacovm
2016-11-09 22:33
Oh

ghaskins
2016-11-09 22:34
I dont think the makefile will set the $PATH

jyellick
2016-11-09 22:34
(Tried running without make, same output)

yacovm
2016-11-09 22:34
I was running compile protos

yacovm
2016-11-09 22:34
Not make protoa

ghaskins
2016-11-09 22:34
yeah, thats all make does

jyellick
2016-11-09 22:34
Just tried `compile_protos.sh` same output

ghaskins
2016-11-09 22:34
it just ensures the pre-requisites are met (in this case, the protoc-gen-go is built) and then calls the script

jyellick
2016-11-09 22:34
``` [yellickj@jmobile fabric]$ ls -lrt vendor/github.com/golang/protobuf/protoc-gen-go/protoc-gen-go -rwxr-xr-x 1 yellickj users 4252498 Nov 9 17:28 vendor/github.com/golang/protobuf/protoc-gen-go/protoc-gen-go ```

yacovm
2016-11-09 22:35
Weird. Using thia trick i was pushing to master and to convergence even though they had different versikns of protocbuf

ghaskins
2016-11-09 22:35
it seems fairly definitive that the .pb.go files you have seem to be properly correlated to the vendored protobuf library

ghaskins
2016-11-09 22:35
now the question is: is that correct?

ghaskins
2016-11-09 22:35
maybe it is

jyellick
2016-11-09 22:35
I have a recollection of, a few weeks ago, it not generating that `// please ugrade ...` message

ghaskins
2016-11-09 22:36
yeah, that is my memory too

ghaskins
2016-11-09 22:36
thus the raising of the issue

ghaskins
2016-11-09 22:36
I suppose its possible that the confusion was the other way around

jyellick
2016-11-09 22:36
But, when I run make protos, it is not claiming that I modify all the protos, despite that line appearing in every output file

ghaskins
2016-11-09 22:36
IsVersion=2 is correct and whatever the other output was was the issue

jyellick
2016-11-09 22:36
Might be... we are not version2 obviously, but maybe from a golang API perspective we still are

ghaskins
2016-11-09 22:37
yeah, its not clear what that refers to

ghaskins
2016-11-09 22:37
it might be a GRPC versioning namespace, orthogonal to protobuf v2 vs v3

ghaskins
2016-11-09 22:37
id have to look again more closely

jyellick
2016-11-09 22:37
@ghaskins When you generate locally, do you get this line?

ghaskins
2016-11-09 22:38
when I run locally, I do not get a diff indicating that it changed

ghaskins
2016-11-09 22:38
so, yes

ghaskins
2016-11-09 22:38
(or, the file isnt being emitted, which is a remote but real possibility

ghaskins
2016-11-09 22:38
long story short, I run "make protos" and I do not see those being removed

ghaskins
2016-11-09 22:39
(which is another data point that its properly correlated, if not correct

jyellick
2016-11-09 22:39
Okay... I will assume things are okay, and post to gerrit as such

ghaskins
2016-11-09 22:39
agreed

ghaskins
2016-11-09 22:39
sorry for the noise

ghaskins
2016-11-09 22:40
any problem here, is not related to your patch

ghaskins
2016-11-09 22:40
and if it is a problem, it will get cleaned up in a follow up sweep

jyellick
2016-11-09 22:42
No problem at all, good to do a little sanity checking on these things once in a while.

yacovm
2016-11-09 22:43
Jyellic, btw- i meant to set the path prefix to be the protoc gen go of the vendor folder, not the go bin or gotools

yacovm
2016-11-09 22:45
But again, maybe it doesnt work in protoc 3.10? I'd run with strace to see what files it touches

jyellick
2016-11-09 23:02
@yacovm I think it was a red herring, and it was using the right proto-gen-go, we just thought the output was incorrect

ghaskins
2016-11-10 01:27

jyellick
2016-11-10 01:28
Done

ghaskins
2016-11-10 01:38
ty

ghaskins
2016-11-10 02:14
does anyone know if there is updated doc for dealing with running things in master?

ghaskins
2016-11-10 02:14
e.g. now we have orderer, membersrvc->cop, and the new SDK

ghaskins
2016-11-10 02:14
I am not clear on how to stand up an environment

jyellick
2016-11-10 03:12
I think @muralisr might have put something together for when he demoed the end to end flow at the hackathon, but not certain

nikileshsa
2016-11-10 04:12
@ghaskins https://lists.hyperledger.org/pipermail/hyperledger-fabric/attachments/20161022/d3860afb/attachment.obj has some documentation on how to deploy and invoke a chaincode. not sure if you are looking for something like this..

hiepnm
2016-11-10 07:56
I have a dummy question about fabric v1.0. In v1.0, Will fabric support validating peers to join dynamically?

garisingh
2016-11-10 10:46
@hiepnm - the short answer is yes The longer answer is things are slightly more complicated while at the same time more flexible. Peers now have 2 types of function - endorsing and committing (endorsing peers typically need to be committing peers as well) and we have introduced an ordering service as well. The basic pattern is that a client / application sends proposals to endorsing peers (which run chaincode to simulate the results), collects endorsed responses, submits them to ordering which then comes back to the committing function of the peers. For the initial version of V1, you'll be able to add endorsing and/or committing peers dynamically

hiepnm
2016-11-10 10:56
@garisingh thank you

ghaskins
2016-11-10 11:40
@jyellick: @nikileshsa ty

muralisr
2016-11-10 12:24
>I think @muralisr might have put something together for when he demoed the end to end flow at the hackathon, but not certain

muralisr
2016-11-10 12:26
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F30R35B51/simple_test_with_skeletal_peer.md and commented: @ghaskins @jyellick the above doc goes over the steps to run end to end test in latest master V1

muralisr
2016-11-10 12:26
We should also have the equivalent flow from SDK too

ghaskins
2016-11-10 12:26
@muralisr ty, and now that I see it, I recall you already sent that to me before

muralisr
2016-11-10 12:26
@jzhang ^^^

ghaskins
2016-11-10 12:26
sorry for the repeat

muralisr
2016-11-10 12:27
no worries at all!!

muralisr
2016-11-10 12:27
one thing to point out

muralisr
2016-11-10 12:28
if we change fabric/peer/core.yaml with the right default we don’t need CORE_PEER_COMMITTER_LEDGER_ORDERER=0.0.0.0:5151 in that doc

muralisr
2016-11-10 12:28
its a nit but I can imagine people getting bitten by that

ghaskins
2016-11-10 12:34
ok, ill try to stand it up later and see what I run into

ghaskins
2016-11-10 12:34
I am in some epic meeting right now

garisingh
2016-11-10 12:36
have fun with that @ghaskins

ghaskins
2016-11-10 12:37
ty, ty

ghaskins
2016-11-10 12:37
one more thing to make my head spin

ghaskins
2016-11-10 12:47
@garisingh so, now that membersrvc is removed from the repo, if I want to run with the SDK, do I just build/stand-up cop in a similar way?

ghaskins
2016-11-10 12:47
(does the SDK even support 1.0 yet?)

ghaskins
2016-11-10 12:48
I know in the past, the SDK could only connect if membersrvc was running even if security was disabled)

ghaskins
2016-11-10 12:48
so I am assuming that is still true, but perhaps it isnt

garisingh
2016-11-10 13:02
the SDKs don't communicate with cop yet (and actually we want to remove the "mandatory" connection going forward - i.e. you should be able to use your own certs if you want). I think the current tests do call out to membership services still using the v0.6.1 Docker image.

ghaskins
2016-11-10 13:12
that makes sense since its largely the architecture I am familiar with

ghaskins
2016-11-10 13:13
@garisingh let me play the first part back: so IIUC, the new SDK can communicate with the master branch peer, but not with security/tcerts/etc

ghaskins
2016-11-10 13:13
?

muralisr
2016-11-10 13:13
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F31JC0MPZ/simple_test_with_skeletal_peer.md and commented: @ghaskins just realized the doc needed to by updated for chaincode naming

ghaskins
2016-11-10 13:14
ah, ty

ghaskins
2016-11-10 13:14
perhaps put this in the wiki?

muralisr
2016-11-10 13:14
(sorry for the interrupt… you had a q. above for @garisingh ….about the doc in the wiki, we could but I don’t know how. Would you be able to do that … or let me know ?)

garisingh
2016-11-10 13:28
@ghaskins - currently the new version of the SDK actually does communicate with the old membersrvcs but the new peer does not do anything to enforce security. @jzhang and team are working to decouple the new SDK from the old membersrvcs

ghaskins
2016-11-10 13:28
related: does that mean I need to be running an old membersrvc to satisfy the login?

ghaskins
2016-11-10 13:29
e.g. 0.6.1-preview?

garisingh
2016-11-10 13:29
actually the peer has no security right now so technically you can interact with the peer without signing anything

garisingh
2016-11-10 13:30
of course the SDK I think might still follow the path of requiring login currently

garisingh
2016-11-10 13:30
so its weird - SDK logs in to old membersrvc but peer could care less

ghaskins
2016-11-10 13:46
thats actually how I have been running for a while now anyway

ghaskins
2016-11-10 13:46
sdk+membersrvc+peer, security off, membersrvc only there to satisfy SDK

ghaskins
2016-11-10 13:47
(I do this because I want to be on top of the SDK so tcerts/ABAC/etc/ will work, but I am not currently testing that part

pd93
2016-11-10 13:48
@muralisr @ghaskins Just noticed.. Line 80 of that doc "Excercise" should probably be "Exercise"

ghaskins
2016-11-10 13:52
@garisingh @muralisr I am going to go through the v1.0 doc today, but based on my new local OSX builds, and see where I get

ghaskins
2016-11-10 13:52
I am looking at what the new workflow might look like

ghaskins
2016-11-10 13:53
I suspect ill need to port my SDK clients though...i guessing the new ES6 API is not ABI compatible with the old TS based one

ghaskins
2016-11-10 13:53
hopefully its not completely orthogonal and then it should go quickly

garisingh
2016-11-10 15:38
I'm going to write-up a requirement on improving the logging infrastructure and possibly implement it too. I was looking at using the logrus package? I'll write up a JIRA entry, but anyone have any other thoughts, objections, etc?

yacovm
2016-11-10 15:39
wasn't @wlahti doing something in the logging area?

garisingh
2016-11-10 15:42
he was making the level dynamically configurable. I see https://jira.hyperledger.org/browse/FAB-61 @binhn - anyone working on this?

ghaskins
2016-11-10 15:46
@pd93 ty for the typo note, btw

wlahti
2016-11-10 15:52
Yes, I added a way to set and get the logging levels dynamically using CLI. That should be able to easily be modified should we switch the underlying logging package, I believe.

wlahti
2016-11-10 15:54
In regards to errors, @hgabor implemented an error handling framework (found in core/errors) which I’ve been working to utilize in the logging code as an example for other components.

garisingh
2016-11-10 15:59
@wlahti - so is the idea to have all components use the fabric/flogging package? There are still places which use go-loggin directly. I was planning to mess around with the flogging package and swap out different loggers to do some testing

hgabor
2016-11-10 16:01
I support the idea to use a common logging technique

hgabor
2016-11-10 16:01
e.g. some kind of fabric level framework

garisingh
2016-11-10 16:01
cool - that's what I was thinking as well

hgabor
2016-11-10 16:02
uh I am a little bit sad that we are on the same page, but.. OK :stuck_out_tongue:

wlahti
2016-11-10 16:08
As far as I’ve seen the flogging package just handles initializing the go-logging levels to default values coming from viper. I’d expect everywhere else to use go-logging directly when defining a new logging module for their code. Correct me if I’m mistaken on any of that though.

hgabor
2016-11-10 16:09
so it is just a configurator module for gologging?

wlahti
2016-11-10 16:12
That’s how I read the code, yes. The only functions beyond LoggingInit, init, and DefaultLoggingLevel are ones I added for dynamically getting/setting the go-logging module levels.

pushpalatha
2016-11-11 03:59
Hi All, In production mode, if i want to refer to some static file from my chain code where do i need to keep it and how to refer it?

jinyu
2016-11-11 07:08
has joined #fabric-dev

chris.zhenghf
2016-11-11 08:40
has joined #fabric-dev

kostas
2016-11-11 09:24
A `make all` for the latest master (`3508592`) fails on the following BDD test: `features/endorser.feature:37 Basic deploy endorsement for chaincode through GRPC to multiple endorsers -- @1.1 Orderer Options`

kostas
2016-11-11 09:24
Is that expected, or is there something wrong with my setup?

muralisr
2016-11-11 13:11
@kostas endorser.feature needs redoing based on all recent changes to protos

kostas
2016-11-11 15:56
@muralisr: Does this affect the CI as well? i.e. Is there any point in me submitting a changeset today?

muralisr
2016-11-11 15:57
@kostas CI has BDD turned off for now till all this activity subsides and @jeffgarratt can look at it wholesale

muralisr
2016-11-11 15:57
so I think you should be fine

kostas
2016-11-11 15:57
Got it, thank you.

muralisr
2016-11-11 15:58
sure…. just to close the loop do look at CI for https://gerrit.hyperledger.org/r/#/c/2409/4 if you like

muralisr
2016-11-11 15:58
has Behave failure that looks like above

jonathanlevi
2016-11-11 16:02

jkilpatr
2016-11-11 16:03
has joined #fabric-dev

jkilpatr
2016-11-11 16:04
that's trying to link against the lastest rocksdb on RHEL 7.3, the goal being RHEL compatibility for the hyperledger project.

jonathanlevi
2016-11-11 16:04
Context: @jkilpatr Justin is trying to work out a costume build (outside Vagrant)

ghaskins
2016-11-11 16:26
@jkilpatr @jonathanlevi I have a parallel effort that would effectively mitigate the need to achieve compatibility with the RHEL layer

ghaskins
2016-11-11 16:27
See the series of patches headed by CR 2321


ghaskins
2016-11-11 16:28
if you check out that CR on top of RHEL, and ensure you have make/git/go(1.6 or later) and an up to date docker/docker-compose, it should all build

jkilpatr
2016-11-11 16:29
@ghaskins that's closer for sure. I'll have to try that commit. Once we build a go binary it just runs natively where ever we ship it right?

ghaskins
2016-11-11 16:29
note that the devenv is no longer needed, I just include it for those that need an easy docker platform

ghaskins
2016-11-11 16:30
@jkilpatr effectively, its because of docker containerization not go, but yes

ghaskins
2016-11-11 16:30
The thesis/rationale is described here: https://gerrit.hyperledger.org/r/#/c/2313/

jkilpatr
2016-11-11 16:30
so a shipping fabric application will always run in docker?

jkilpatr
2016-11-11 16:30
aka when the end user is using a final implementation it will still depend on docker?

ghaskins
2016-11-11 16:30
well, its just a proposal at this point

ghaskins
2016-11-11 16:31
but yes, that is the propsal

ghaskins
2016-11-11 16:31
effectively, we already do depend on it because of the chaincode

jkilpatr
2016-11-11 16:31
ok so right now native targets are built

jkilpatr
2016-11-11 16:31
sorry i don't know much of the current state, much less the proposed state

ghaskins
2016-11-11 16:31
and we make it harder on ourselves by trying to support building both native and docker binaries

ghaskins
2016-11-11 16:32
so, the proposal is, fully embrace the one we are bound to support anyway, stop trying to support both

jkilpatr
2016-11-11 16:33
is it really so difficult to create a platform agnostic dev env? I guess containers make for easier shipping but it seems very messy compared to more traditional linux projects, which I'm probably just more used to.

ghaskins
2016-11-11 16:33
right now you can build both native artifacts, and docker artifacts

ghaskins
2016-11-11 16:33
part of the problem has been rocksdb

ghaskins
2016-11-11 16:33
there wasnt broad community packaging for it, at least in a consistent manner

jkilpatr
2016-11-11 16:34
IMO this is just taking the "well it works on my machine" from a dev and then shipping a copy of that guys hdd to everyone, sure it works but *cringe*

ghaskins
2016-11-11 16:34
I dont see it that way at all

ghaskins
2016-11-11 16:34
Let me give my perspective

ghaskins
2016-11-11 16:34
its not about "im lazy and this works, so ship the sloppy thing"

ghaskins
2016-11-11 16:35
its about bundling, encapsulation, etc

ghaskins
2016-11-11 16:36
docker really leans towards "its a process"...except that process can be more than just a binary...it can include any of the resources it needs

ghaskins
2016-11-11 16:36
I equate it to being like an uberjar

jkilpatr
2016-11-11 16:36
I agree containers aren't inherently lazy, but if I want a full dependencies list for an arbitrary platform it's not provided (at least in the docs I've managed to find) its "whatever is in this image"

ghaskins
2016-11-11 16:37
jvm applications have had this bundling concept forever, it can be self contained and all you need is the jvm form factor...docker is kind of like that but in a completely language neutral way

ghaskins
2016-11-11 16:37
so it doesnt matter if its jvm, node, go, c++, whatever, I can bundle an app into a neutral formfactor and thus simplify the dep graph

ghaskins
2016-11-11 16:38
i see value there

ghaskins
2016-11-11 16:38
and that aside, we _have_ to support docker anyway, as its how we isolate chaincode instances

ghaskins
2016-11-11 16:38
so, the struggle was trying to support both native and docker..the thought was, we require docker, punt on native

ghaskins
2016-11-11 16:39
now, instead of doing "peer", you do "docker run ...peer", but its more or less the same thing except you greatly reduced the requirements on the environment to just "modern docker"

ghaskins
2016-11-11 16:40
rather than "rocksdb 4.1, protobuf v3.1, golang v1.7" etc etc

jkilpatr
2016-11-11 16:40
I don't think we're going to resolve one of the bigger arguments in modern computing today, but I would like to do more documenting on what exactly the container needs to have. Sure you punt the complexity at the user level, but I would prefer we knew exactly what was in the container rather than having to go and dig into it to find out.

ghaskins
2016-11-11 16:40
ok, i have no problem with that

ghaskins
2016-11-11 16:41
also, to be clear: I am not _introducing_ docker containers...we already had those. I am merely dropping native artifacts

ghaskins
2016-11-11 16:41
but wanting to know whats inside is perfect fair

jkilpatr
2016-11-11 16:42
I know, I've played with most of it so far. I have no inherent dislike for containers or docker, I've just dealt with docker projects that a year or two later need to be revived-updated and you can't figure out why the container ever worked in the first place, which is very frustrating.

ghaskins
2016-11-11 16:42
im just pointing out that I am reducing entropy, not adding to it :wink:

ghaskins
2016-11-11 16:43
I know where you are coming from @jkilpatr though...i used to work for Suse where we did much more traditional linux packaging

ghaskins
2016-11-11 16:43
rpms, etc

ghaskins
2016-11-11 16:44
this is the first project ive been on where its heavily vagrant/docker based, so it was a shift for me

ghaskins
2016-11-11 16:44
but after working with it, I am seeing some value...part of it is driven by the fact that some of the dependencies are not standard

ry
2016-11-11 16:44
for the better or worse?

ry
2016-11-11 16:44
or just different

ghaskins
2016-11-11 16:45
honestly, i am kind of pro container right now

ghaskins
2016-11-11 16:45
dependency hell sucks...its manageable when your target is one distro

ghaskins
2016-11-11 16:45
for a project like this, its hairy

ghaskins
2016-11-11 16:46
if every distro in the world was shipping librocksdb forever, proto3 had been stable for years, golang 1.7 was the standard, etc, etc, it would be perhaps a different conversation

ghaskins
2016-11-11 16:47
but the lightbulb turned on for me when I started thinking about how my clojure applications were interacting with the world

ry
2016-11-11 16:47
interesting. I should probably go through similar growth :slightly_smiling_face:

ghaskins
2016-11-11 16:48

ghaskins
2016-11-11 16:48
and as long as your platform has bash and jre, it will run

ghaskins
2016-11-11 16:48
that is freakin cool

ghaskins
2016-11-11 16:48
no more of this @#$ I used to have to deal with with making sure you have libboost_threads-1.59.so, but not libboost_threads-1.60.so, etc

ghaskins
2016-11-11 16:49
docker kind of does that _for anything_

ghaskins
2016-11-11 16:49
brb

ghaskins
2016-11-11 16:52
anyway, im not saying its perfect, but it is interesting

ghaskins
2016-11-11 16:53
and like I mentioned, we _need_ docker anyway...and people were really struggling with the devenv/no-devenv thing

ghaskins
2016-11-11 16:54
im some ways, I think the old model was solving a different problem set

ghaskins
2016-11-11 16:55
the whole .so thing is structured around certain efficiencies (such as disk space, ram, etc), but it does carry a complexity cost

ghaskins
2016-11-11 16:57
certain platforms have already eschewed that notion (for instance, java and golang tend to produce "static" objects) that dont have many outside dependencies

ghaskins
2016-11-11 16:57
but, as we see in this case, they can still be a bit leaky in the form of native integrations (JNI, linking to librocksdb.so, etc)

ry
2016-11-11 17:04
sure. This is an issue we struggled with on my previous project, but a lot of the platforms were not powerful enough to resolve it elegantly. We went with static binaries when we needed to, and it's still broken on some popular platforms (Windows, OpenWRT, Android)

ghaskins
2016-11-11 17:05
in the end, the pain point (for me, in particular) is the maintenance of the devenv juxtaposed against half the people refusing to use it

ghaskins
2016-11-11 17:06
it wouldnt be hard for me to simply leave the support for native build in place as an unsupported alternative

ghaskins
2016-11-11 17:06
i was originally of the mindset that, simple is better, but maybe flexible is better, I dont know

jkilpatr
2016-11-11 17:06
in the ideal world you could just keep moving upstream until all your dependcies where fixed

jkilpatr
2016-11-11 17:07
and then dependency hell would be easier to resolve. but that's not feasible.

ghaskins
2016-11-11 17:07
basically, i could just drop CR 2313 from the series, and declare we wont produce more devenv baseimages, and let people that want to wrestle with it, wrestle with it

ry
2016-11-11 17:09
at the cost of lower adoption

ghaskins
2016-11-11 17:09
@jkilpatr yes, though I think the confluence of circumstances here make that challenging

ry
2016-11-11 17:09
but, at the benefit of less of your time burned on system administration-type tasks

ghaskins
2016-11-11 17:10
@ry: which drives lower adoption?

ghaskins
2016-11-11 17:10
the move to docker? something else?

jkilpatr
2016-11-11 17:10
more difficult to deploy

ry
2016-11-11 17:10
ghaskins if getting your development environment takes 25 finicky steps, fewer people survive onboarding

jkilpatr
2016-11-11 17:10
but I've found that native jenkins is easier to run than container jenkins, its about the quality of the packaging and the container

ghaskins
2016-11-11 17:10
but this would be an improvement on that metric, no?

ry
2016-11-11 17:11
ghaskins yes, I am not only agreeing with you, but (I think) reinforcing your point

ghaskins
2016-11-11 17:11
oh, ok

ghaskins
2016-11-11 17:11
i misunderstood, sorry

ry
2016-11-11 17:11
perhaps I'm a quart low on blood and not thinking clearly :slightly_smiling_face:

ghaskins
2016-11-11 17:11
well, i hope not, as that means I am too :wink:

ghaskins
2016-11-11 17:12
anyway, @jkilpatr i think if you play around with the new stuff I am proposing, its actually as close to turnkey as I think it could ever be

ghaskins
2016-11-11 17:13
I can take a totally clean system and (once its committed/released) just do "docker run -t hyperledger/fabric-peer"

ghaskins
2016-11-11 17:13
and done...downloads everything you need, peer starts up, and you are running

ghaskins
2016-11-11 17:14
integration with something like a fabric-peer.rpm would probably involve the proper init.d minutiae to drive that process

jkilpatr
2016-11-11 17:14
is that pull probable to go through?

ghaskins
2016-11-11 17:14
why not?

jkilpatr
2016-11-11 17:15
just don't know the lay of the land.

ghaskins
2016-11-11 17:15
oh, you mean the CR?

ghaskins
2016-11-11 17:15
(sorry, i took pull == docker pull)

jkilpatr
2016-11-11 17:15
yup, sorry I should have been more clear.

ghaskins
2016-11-11 17:16
my gut is, it has a shot as @cbf and @garisingh have been supportive

ghaskins
2016-11-11 17:16
but I havent yet got the kinks worked out such that we have had a real discussion yet

ghaskins
2016-11-11 17:16
I have the series all working locally, but trying to sort out some CI infra issues with @ry so the tests can start to pass

ghaskins
2016-11-11 17:17
once I can get it running through CI, I can propose it as a more serious discussion with the other maintainers and community

ghaskins
2016-11-11 17:17
your input is certainly welcome too

ghaskins
2016-11-11 17:18
for instance, if you feel strongly that we need native support to remain, that is valuable feedback

jkilpatr
2016-11-11 17:18
I feel that there should always be enough documentation that native builds are possible, even if its so many steps most people throw their hands up and go with docker (for good reason)

jkilpatr
2016-11-11 17:19
otherwise someday the container breaks or needs to be updated/changed and no one understands why it works in the first place.

ghaskins
2016-11-11 17:19
sure, thats fair...the main painpoint for me is the vagrant devenv that we currently need to reliably build native is a PITA to support

ghaskins
2016-11-11 17:20
so, I dont mind leaving the build directives for native in place, as long as I dont have to support them :wink:

ghaskins
2016-11-11 17:21
actually, I wouldn't really mind continuing to support vagrant, but the broader issue is there is a large group of users who, for whatever reason, wont use it

garisingh
2016-11-11 17:21
Like me!

ghaskins
2016-11-11 17:21
and are thus always complaining that their builds fail, heh

garisingh
2016-11-11 17:21
But I don't complain

ghaskins
2016-11-11 17:21
no, you dont

jkilpatr
2016-11-11 17:21
getting vagrant working was an enormous pita on my fedora machine.

ghaskins
2016-11-11 17:21
but I get plenty that do

garisingh
2016-11-11 17:22
And there is actually enough here to figure out native builds from all of your work

ghaskins
2016-11-11 17:22
so, i see this as a way to really broaden the platforms that _can_ build everything more than anything else

ghaskins
2016-11-11 17:23
and also, I personally dont see the problem changing "peer" to "docker run peer"

garisingh
2016-11-11 17:23
I've done it in Mac, Linux and Windows

ghaskins
2016-11-11 17:23
but maybe not everyone will feel that way

garisingh
2016-11-11 17:23
Getting rid of RocksDB helps now too

garisingh
2016-11-11 17:23
Sure

ghaskins
2016-11-11 17:23
you have run my new series on docker-for-windows?

garisingh
2016-11-11 17:23
I'm willing to help moving forward as well

garisingh
2016-11-11 17:23
Not yet

garisingh
2016-11-11 17:24
I ran pure native on windows

ghaskins
2016-11-11 17:24
ah, gotcha

ghaskins
2016-11-11 17:24
if you have a windows setup and can test that, I would like to know

ghaskins
2016-11-11 17:24
ive tested mac/linux, but I dont have windows handy

jkilpatr
2016-11-11 17:27
where do I find the dockerfile for this stuff?

ghaskins
2016-11-11 17:27
general flow is ./images/xxx/Dockerfile.in becomes ./build/images/xxx/Dockerfile at build time

jkilpatr
2016-11-11 17:30

jkilpatr
2016-11-11 17:30
where do find that dockerfile?


jkilpatr
2016-11-11 17:32
cool thanks

ghaskins
2016-11-11 17:32
yw

ghaskins
2016-11-11 17:33
for the complete picture, today, fabric-baseimage.git defines the instructions for "baseimage" which is generated for 4 targets

ghaskins
2016-11-11 17:33
1) x86_64 vagrant/devenv, 2) x86_64 docker, 3) ppcle64 docker, 4) s390x docker

ghaskins
2016-11-11 17:34
so, when you build native from either devenv, or build docker, you are getting your dependencies from what is defined in that fabric-baseimage.git recipe

ghaskins
2016-11-11 17:35
some people use the vagrant setup, some people go off on their own, and in a least a few cases, others have contributed back their own environments



ghaskins
2016-11-11 17:37
the goal of my effort mentioned above is to obsolete (1) and those community.sh scripts

ghaskins
2016-11-11 17:38
make it so all you need is docker, and the rest will work within (2)(3)(4)

jkilpatr
2016-11-11 17:43
how do you get cross compatibility? cross compile in the container itself?

jkilpatr
2016-11-11 17:43
well I guess it wouldn't be cross compile at that point now would it.

ghaskins
2016-11-11 17:49
its done via native jenkins workers

ghaskins
2016-11-11 17:49
look on the lower left: https://jenkins.hyperledger.org/

ghaskins
2016-11-11 17:50
power-[1-5] and linuxone-[2-3] do the ppcle and s390x builds, respectively

ghaskins
2016-11-11 17:50
x86 is spawned on demand from an IAAS provider

ghaskins
2016-11-11 17:51
we also manage it as an overlay at runtime by using docker tags

jkilpatr
2016-11-11 17:51
wow you go your hands on that sort of hardware

ghaskins
2016-11-11 17:51
e.g. peer:x86_64 vs peer:s390x

ghaskins
2016-11-11 17:51
not me personally

jkilpatr
2016-11-11 17:51
any reason to not just cross compile?

ghaskins
2016-11-11 17:52
not sure, i didnt try...the P/Z teams did their own thing

jkilpatr
2016-11-11 17:53
ok then. ¯\_(ツ)_/¯

jkilpatr
2016-11-11 17:53
cool hardware though.

ghaskins
2016-11-11 17:53
yeah

oiakovlev
2016-11-11 19:16
Hi QQ: is there any signing transaction mechanism exist in HL? So let's say to check if transaction was signed by user A, for example? I realize that we can implement such signatures using certificate attributes, for example, and store the result in KVS. But something out of the box? I'm talking in the view of v06 and also curious about plans for v1?

subzer0
2016-11-12 20:16
has joined #fabric-dev

wale
2016-11-13 01:12
has joined #fabric-dev

rickr
2016-11-13 19:24

rickr
2016-11-13 19:24
For the ChaincodeID I've only set the name not the path in the past. Not sure where it's getting `default`/example_cc.go The example_cc.go is the name I set in the ChaincodeID

rickr
2016-11-13 19:49
Even setting the ChaincodeID path to something I get that same error

aso
2016-11-13 21:27
Hi @oiakovlev > Hi QQ: is there any signing transaction mechanism exist in HL? So let's say to check if transaction was signed by user A, for example? I realize that we can implement such signatures using certificate attributes, for example, and store the result in KVS. But something out of the box? > I'm talking in the view of v06 and also curious about plans for v1? Yes there are indeed plans - take a look at https://gerrit.hyperledger.org/r/#/c/2453

oiakovlev
2016-11-13 21:34
Thanks @aso - guess this is only for v1, right? so v06 has no these options - at least I have not found) And also is there any related ticket describing the idea?

xixuejia
2016-11-14 00:28
has joined #fabric-dev

yaoguo
2016-11-14 06:57
@aso why do you want to store the check result in KVS? usually check this in chaincode is enough.

aso
2016-11-14 07:25
@oiakovlev I think it's for v1, @garisingh would know for sure

aso
2016-11-14 07:25
@yaoguo which check result are you referring to?

yaoguo
2016-11-14 07:29
@aso I thought the result said by @oiakovlev is `check if transaction was signed by user A`.

yaoguo
2016-11-14 07:31
for v0.6, we can signing tx with Ecert or Tcert.

oiakovlev
2016-11-14 07:37
what I want to achieve is to be able to sign transaction by user A, than appon approval of user B - sign it by user B and so on, so ledger will have some sort of signatures. @yaoguo If I'm not mistaken - what we have in v06 and what are you telling - is just signing transaction by user certificate - upon execution. What I want is a bit more complicated scenario.

yaoguo
2016-11-14 08:00
sorry for misread. in v0.6, transaction has a `signature` field. peer will help you to sign transaction if you specify user. the approval is implemented by membership service. you can see more at https://github.com/hyperledger/fabric/blob/v0.6/docs/protocol-spec.md#42-user-privacy-through-membership-services

yaoguo
2016-11-14 08:01
@oiakovlev

oiakovlev
2016-11-14 08:05
thanks, just curious - can signature contain few signatures in it? Maybe I have read the link .. first..before asking :slightly_smiling_face:

yaoguo
2016-11-14 08:25
for v0.6, there's only one signature. I don't know the scenario of few signatures. maybe you want hierarchical identity based signature?

oiakovlev
2016-11-14 08:46
just let's say - transfer between accounts should be signed by 2 entities + some approval entity. For approval entity and each of involved entities - there can be hierarchy but guess that between 2 involved - there is no hierarchy...

yaoguo
2016-11-14 09:25
@oiakovlev that sounds like endorse mechanism in v1.0. a transaction need be endorsed by endorsers. then transaction contains signatures of multiple endorsers.

oiakovlev
2016-11-14 09:26
yes, it make sense. Thanks.

aso
2016-11-14 09:38
@oiakovlev > just let's say - transfer between accounts should be signed by 2 entities + some approval entity. For approval entity and each of involved entities - there can be hierarchy but guess that between 2 involved - there is no hierarchy... I think endorsement policies might be of interest for you. Take a look at https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md

oiakovlev
2016-11-14 09:39
yes, I have read about it - it make sense what you're saying, thanks

vdods
2016-11-14 22:15
I've got a question about ChaincodeStubInterface GetRows method -- you can specify a partial key, but is it only a partial prefix? Not an arbitrary subset of keys? I.e. if the keys are A B C D, then you could specify A B C D, or A B C, or A B, or A, or <empty>, but no other combinations, such as B D. Is that correct?

vdods
2016-11-14 22:56
I think it must be the case because there's no way to specify along with `keys []*shim.Column` the column names, should you want to specify a non-prefix subset of keys.

jzhang
2016-11-15 03:05
@binhn @garisingh would the “system ledger” be created just as another channel (believe that’s my understanding from chatting with you on Friday) or it’s joined by all Peers by default?

jzhang
2016-11-15 03:06
the SDK work group had this question during our design review

abhishekseth
2016-11-15 06:02
Hey all, I am running with a setup which has two peers running on two different physical machines. When security was not enabled, i was able to have communication between them. But now, I have security enabled and now the peers are not able to communicate and it is giving certification error. I am using the following docker-compose.yaml file: # membersrvc: # image: hyperledger/fabric-membersrvc # ports: # - "50051:50051" # - "7054:7054" # command: membersrvc vp1: image: hyperledger/fabric-peer ports: - "5000:5000" - "7051:7051" - "7050:7050" - "30303:30303" - "30304:30304" environment: - CORE_PEER_ADDRESSAUTODETECT=false - CORE_VM_ENDPOINT=unix:///var/run/docker.sock - CORE_LOGGING_LEVEL=DEBUG - CORE_PEER_ID=vp1 - CORE_SECURITY_ENABLED=true #- CORE_SECURITY_PRIVACY=true - CORE_SECURITY_ENROLLID=test_vp0 - CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT - CORE_PEER_DISCOVERY_ROOTNODE=9.109.251.105:7051 - CORE_PEER_PKI_ECA_PADDR=9.109.251.105:7054 - CORE_PEER_PKI_TCA_PADDR=9.109.251.105:7054 - CORE_PEER_PKI_TLSCA_PADDR=9.109.251.105:7054 - CORE_CHAINCODE_DEPLOYTIMEOUT=180000 # - MEMBERSRVC_CA_ACA_ENABLED=true volumes: - /var/run/docker.sock:/var/run/docker.sock # links: # - membersrvc command: sh -c "sleep 5; peer node start” Any help is appreciated.

oiakovlev
2016-11-15 08:04
in your docker-compose you have commented membersrvc, which is responsible for security, so how would it work? :slightly_smiling_face:

oiakovlev
2016-11-15 10:52
Hi is there any example exist of event listener example (similar to https://github.com/hyperledger/fabric/tree/master/examples/events/block-listener) but based on NodeJS SDK? I guess that this support has been added, here: https://github.com/hyperledger/fabric/commit/e9d3ac296de89a092b48990fd2e1b7bc4173a5c4. Right?

kostas
2016-11-15 14:41
Whenever we mess around with the protos, can we do the `@channel` thingy here?

yacovm
2016-11-15 14:43
maybe it is possible to have some gerrit hook that sends you an email when a commit touches a certain folder

jzhang
2016-11-15 20:07
@binhn @garisingh @tim.s about my questions above, from talking to @jyellick today, it looks like the latest thinking is to not have a default “system channel”, but instead have all channels be created after the bootstrap as per the channel/ledger design doc. this is consistent with my understanding from talking to Binh last Friday.

tim.s
2016-11-15 20:07
has joined #fabric-dev

jzhang
2016-11-15 20:10
@tim.s so the main reason based on talking with Jason is that there’s no serialization/ordering guarantee across channels b/w peers, such that one peer may have the “system ledger” in one state (that may have the latest CA roots saved), and another peer’s system ledger in a different state (hasn’t had the latest CA roots saved in the genesis block yet), which will result in non-deterministic behaviors with Peers in a channel

vdods
2016-11-15 20:49
I've been working on fixing some bugs in MockStub and am wondering what the workflow you guys use is -- because the work is done on http://gerrit.hyperledger.org but the golang import path is http://github.com/hyperledger/fabric, is there some particular customization that's used for pushing changes, such as cloning the github repo but setting the 'push' remote to be gerrit?

vdods
2016-11-15 20:50
(I'd like to push my fixes to gerrit at some point)

vdods
2016-11-15 20:51
Sorry, I just found some docs on that -- I'll read those and hopefully not have any questions

vdods
2016-11-16 05:43
Ok, apart from using git-review to submit changes to Gerrit for review, is there anything else I need to do?

vdods
2016-11-16 05:46
Like maybe add a reviewer

ry
2016-11-16 06:08
@vdods yes you will need to add a reviewer and flog the commit in #fabric-pr-review if it needs love

ry
2016-11-16 06:08
@vdods add cr-fabric to reviewers if you want them all

vdods
2016-11-16 06:08
@ry Is there a particular owner of the shim code, or maybe MockStub in particular?

ry
2016-11-16 06:09
@vdods I don't know the answer to that, sorry.

vdods
2016-11-16 06:09
@ry Ok, thanks for the instruction!

ry
2016-11-16 06:09
if you have any questions about gerrit in general or the review process, I can help with that.

ry
2016-11-16 06:09
sure thing

z21921
2016-11-16 09:32
has joined #fabric-dev

ghaskins
2016-11-16 16:19
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F32M9FVHN/-.pl and commented: @muralisr ever see the circumstance where the peer only seems to be listening on IPv6 ?

emtrevin
2016-11-16 16:32
has joined #fabric-dev

scottz
2016-11-16 16:55
I could use some advice on gerrit procedures. After my first set of files were reviewed in gerrit, I made fixes, using a new commit. The instructions say to use the same change ID when revising code after inspections; should I edit my latest commit patchset using "git commit -s --amend" and change the newly provided changeID to the one used for the prior commit, before I push the new patchset? If it is bad to edit the changeID at this point, then how would I close off the original patchset as well as my new patchset (after it gets approved)?

tuand
2016-11-16 16:56
do `commit --amend` then `git push origin HEAD:refs/for/master`

ry
2016-11-16 16:57
scottz yes, reuse your original change ID

ghaskins
2016-11-16 16:57
@scottz gerrit will understand that pushing the different version of the patch with the same ChangeID is an update to the original, and create a new version

ry
2016-11-16 16:57
well wait, how did you fix them? is it a new commit on top of the old commit?

ghaskins
2016-11-16 16:58
@muralisr nevermind my q above...aside from the confusing netstat nomenclature, it does seem to be listening on IPv4 too

ry
2016-11-16 16:58
if you now have two commits, the original commit and the new commit with fixes, you should squash them (git rebase -i or similar) and reuse the original commit id

ghaskins
2016-11-16 16:58
I had a calamity of errors in my use of netstat + nmap that led me down a rabbit hole

ghaskins
2016-11-16 16:59
@ry: good point

ghaskins
2016-11-16 17:00
not that I want to add confusion to the mix, but I use stgit to manage all this...its very nice way to curate a series

ry
2016-11-16 17:03
I suggest anyone just getting started follow @ghaskins' tooling advice, as I still disclaim ANSI C as too newfangled to trust

ghaskins
2016-11-16 17:05
my understanding is the path of least friction with gerrit is to use git-review

ghaskins
2016-11-16 17:06
though I have never done this, as ive been using stgit for years

scottz
2016-11-16 17:06
thx; since I already created a new commit, I will try to squash and then push again. i hope this does not mess up the existiing review records.

ghaskins
2016-11-16 17:06
for the most part, stgit is a good model though there are a few warts when dealing with gerrit

ghaskins
2016-11-16 17:07
for one, the commit-hook doesnt fire when you add a patch via stgit...

ghaskins
2016-11-16 17:07
(the one that assigns a changeid

ghaskins
2016-11-16 17:07
so, i have to do a little dance to work around that

ry
2016-11-16 17:07
scottz which commit are you working on?


scottz
2016-11-16 17:08
yes. branch v6: e606a60ed64e962ddf4695a82ed130fc693d3d8, and new commit 99ccda1867306f13ed86f15ff9d2a1ac8186cefe

ry
2016-11-16 17:09
it looks like you never pushed the unsquashed commits, so as long as you reuse the change ID, the review records will match

ry
2016-11-16 17:10
and you'll be pushing to refs/for/v0.6 instead of the refs/for/master as noted above

scottz
2016-11-16 17:16
correct, I never pushed the new commit. ok.

ry
2016-11-16 17:37
scottz looks like it worked!

scottz
2016-11-16 17:38
yes I am verifying, and agree it looks good. I rebased, and edited the changeid when amended the commit msg. thanks.

scottz
2016-11-16 17:46
will a notification get sent to all the reviewers automatically saying it is updated and ready for re-review?

ry
2016-11-16 17:49
they should get an email if they signed up for emails, yes.

aso
2016-11-16 21:24
is this CI failure expected? ``` # http://github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb vendor/github.com/tecbot/gorocksdb/backup.go:4:24: fatal error: rocksdb/c.h: No such file or directory // #include "rocksdb/c.h" ^ compilation terminated. FAIL http://github.com/hyperledger/fabric/core [build failed] ```

aso
2016-11-16 21:25
it's from a "new" jenkins run `fabric-verify-d112-x86_64`

yacovm
2016-11-16 21:25
I would guess that is related to a new build type that doesn't rely on vagrant, am I right @ghaskins ?

ghaskins
2016-11-16 21:25
ignore any -d112 output

ghaskins
2016-11-16 21:26
its an experiment that @ry and I are conducting, it was supposed to be behind the scenes

ghaskins
2016-11-16 21:26
not sure why it even bubbled up

aso
2016-11-16 21:26
unfortunately it still -1's my change set

yacovm
2016-11-16 21:26
I think you can still merge a -1

ghaskins
2016-11-16 21:26
@ry: ^^^^

yacovm
2016-11-16 21:26
can't you?

aso
2016-11-16 21:26
probably true

ry
2016-11-16 21:26
ah the -112 changes shouldn't be voting, if they are that's an error, let me look could you link to the exact failed build please?

yacovm
2016-11-16 21:26
just saying, of course

aso
2016-11-16 21:26
anyway, thx!


aso
2016-11-16 21:27
you won't find the -1 now because I've rebased in the meantime

ry
2016-11-16 21:28
OK I will wait until it fails, that job shouldn't have any output to gerrit in the current iteration

yacovm
2016-11-16 21:28
@muralisr ^ that's the reason for the -1 failure

yacovm
2016-11-16 21:29
it was actually supposed to be a +1

ry
2016-11-16 21:31
OK I manually made it silent I don't know why setting the two silent options didn't work

aso
2016-11-16 21:34
thx!

aso
2016-11-16 21:46
@ry https://gerrit.hyperledger.org/r/#/c/2453/ -1 and yet the CI run was successful

ry
2016-11-16 21:47
aso: I removed the -1, Gari will need to over-ride it

aso
2016-11-16 21:47
thx!

aso
2016-11-16 21:48
yeah, @garisingh 's -2 was because that change-set started as a WIP but now it's ready

aso
2016-11-16 21:48
at any rate, thx @ry

ry
2016-11-16 21:50
could you help me out, aso?

aso
2016-11-16 21:51
sure, what can I do for you?

ry
2016-11-16 21:51
please add this line: `Signed-off-by: Elli Androulaki <lli@zurich.ibm.com>` as indicated to the commit message

ry
2016-11-16 21:52
that makes machine parsing of the git log for DCO compliance much easier

aso
2016-11-16 21:52
so the commit msg should have 2 sign-offs?

ry
2016-11-16 21:53
yes. just add the additional line (git commit --amend)

ry
2016-11-16 21:53
or whatever workflow you use

aso
2016-11-16 21:53
sure, will do

ry
2016-11-16 21:53
thank you. A commit message update might not trigger a full CI pass

aso
2016-11-16 21:53
it usually does

aso
2016-11-16 21:53
oh well :slightly_smiling_face:

ry
2016-11-16 21:54
c'est la vie

aso
2016-11-16 21:54
btw: DCO compliance?

aso
2016-11-16 21:54
(out of curiosity)

ry
2016-11-16 21:55
ah, developer certificate of origin? you're saying you wrote it and it isn't encumbered. in this case you are using code from someone else that already did that, so you just need to copy that line over


ry
2016-11-16 21:55
wow, I expanded the acronym correctly for once

aso
2016-11-16 21:56
:smile:

aso
2016-11-16 21:56
right, I actually thought about doing that but concluded that given that Elli and I work in the same team I could dispense with that

aso
2016-11-16 21:56
but I'm happy to do it anyway

aso
2016-11-16 21:56
thx!

ry
2016-11-16 21:57
the issue is Elli's code isn't merged, and if it doesn't get merged, that information is lost

aso
2016-11-16 21:57
gotcha

ry
2016-11-16 21:57
in the far future when hyperledger's gerrit no longer exists

ry
2016-11-16 21:57
anyway, thank you

aso
2016-11-16 21:57
I'll keep that in mind next time, thx!

pushpalatha
2016-11-17 09:31
HI All, The Invoke method if i return something, why i can't see that in the response ? It always returns something like : { "jsonrpc": "2.0", "result": { "status": "OK", "message": "b7e86ac5-02e6-46da-a3d2-7483d45630bf" }, "id": 3 } plz help

pushpalatha
2016-11-17 09:46
why the invoke syntax has return type []byte and error both when we can't return any messages as it's async call?

bryan-huang
2016-11-17 12:01
Hi

bryan-huang
2016-11-17 12:01
did anyone see following error:

bryan-huang
2016-11-17 12:02
consensus/pbft] Checkpoint -> DEBU 2104 Replica 0 preparing checkpoint for view=0/seqNo=8 and b64 id of CAkSQDJ1YvmpxsBoen9tXvCHly+XapthAGsQDnodrkqEm7GkZLGIzD0GW3k7hd3pnrZF58+0Qe2sA2IlVhP+YJJgBi8aQA8ew7BfByr4DP1hZVaYiBbjN2/1HKNW1okFVD54Txn9VtG/XzKxiaE16q0PKNVFQavX4/N+fqw5rX8UuZJtRYo= 11:54:36.652 [consensus/pbft] recvCheckpoint -> DEBU 2105 Replica 0 received checkpoint from replica 0, seqNo 8, digest CAkSQDJ1YvmpxsBoen9tXvCHly+XapthAGsQDnodrkqEm7GkZLGIzD0GW3k7hd3pnrZF58+0Qe2sA2IlVhP+YJJgBi8aQA8ew7BfByr4DP1hZVaYiBbjN2/1HKNW1okFVD54Txn9VtG/XzKxiaE16q0PKNVFQavX4/N+fqw5rX8UuZJtRYo= 11:54:36.652 [consensus/pbft] recvCheckpoint -> DEBU 2106 Replica 0 found 1 matching checkpoints for seqNo 8, digest CAkSQDJ1YvmpxsBoen9tXvCHly+XapthAGsQDnodrkqEm7GkZLGIzD0GW3k7hd3pnrZF58+0Qe2sA2IlVhP+YJJgBi8aQA8ew7BfByr4DP1hZVaYiBbjN2/1HKNW1okFVD54Txn9VtG/XzKxiaE16q0PKNVFQavX4/N+fqw5rX8UuZJtRYo= 11:54:36.653 [consensus/pbft] recvCheckpoint -> CRIT 2107 Network unable to find stable certificate for seqNo 8 (3 different values observed already) panic: Network unable to find stable certificate for seqNo 8 (3 different values observed already) goroutine 38 [running]: panic(0xc13e20, 0xc820aa8f00) /opt/go/src/runtime/panic.go:464 +0x3e6 http://github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc820161d40, 0x103cce0, 0x5d, 0xc8209f47a0, 0x2, 0x2) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x11e http://github.com/hyperledger/fabric/consensus/pbft.(*pbftCore).recvCheckpoint(0xc8202c0680, 0xc8209f4760, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/consensus/pbft/pbft-core.go:1185 +0xcc7 http://github.com/hyperledger/fabric/consensus/pbft.(*pbftCore).Checkpoint(0xc8202c0680, 0x8, 0xc820c35680, 0x86, 0xa0) /opt/gopath/src/github.com/hyperledger/fabric/consensus/pbft/pbft-core.go:988 +0x57e http://github.com/hyperledger/fabric/consensus/pbft.(*pbftCore).execDoneSync(0xc8202c0680) /opt/gopath/src/github.com/hyperledger/fabric/consensus/pbft/pbft-core.go:997 +0x215 http://github.com/hyperledger/fabric/consensus/pbft.(*pbftCore).ProcessEvent(0xc8202c0680, 0xc30220, 0x15ffd38, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/consensus/pbft/pbft-core.go:386 +0x1843 http://github.com/hyperledger/fabric/consensus/pbft.(*obcBatch).ProcessEvent(0xc820388240, 0xc30220, 0x15ffd38, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/consensus/pbft/batch.go:367 +0xbc6 http://github.com/hyperledger/fabric/consensus/util/events.SendEvent(0x7f81732a0078, 0xc820388240, 0xda3a60, 0xc8209f4660) /opt/gopath/src/github.com/hyperledger/fabric/consensus/util/events/events.go:113 +0x45 http://github.com/hyperledger/fabric/consensus/util/events.(*managerImpl).Inject(0xc820390c80, 0xda3a60, 0xc8209f4660) /opt/gopath/src/github.com/hyperledger/fabric/consensus/util/events/events.go:123 +0x4f http://github.com/hyperledger/fabric/consensus/util/events.(*managerImpl).eventLoop(0xc820390c80) /opt/gopath/src/github.com/hyperledger/fabric/consensus/util/events/events.go:132 +0xdb created by http://github.com/hyperledger/fabric/consensus/util/events.(*managerImpl).Start /opt/gopath/src/github.com/hyperledger/fabric/consensus/util/events/events.go:100 +0x35

garisingh
2016-11-17 13:18
@bryan-huang - your peer is no longer in sync with the rest of the network

bryan-huang
2016-11-17 13:43
@garisingh thx a lot for your answer, but how could this happen, was it caused by the chaincode?

bryan-huang
2016-11-17 13:44
the configuration of pbft checkpoint is K=2

garisingh
2016-11-17 13:44
what kind of setup are you running?

bryan-huang
2016-11-17 13:44
one box, docker compose 4

bryan-huang
2016-11-17 13:44
vps

garisingh
2016-11-17 13:45
is the chaincode running for each of the 4 peers?

bryan-huang
2016-11-17 13:45
this one docker-compose-4-consensus-batch.yml

bryan-huang
2016-11-17 13:45
yes

garisingh
2016-11-17 13:46
you might want to use the REST API and take a look at the blocks / transactions on each peer and see where the difference occurred

garisingh
2016-11-17 13:46
meaning compare the block heights, blocks and transactions of the peer that crashed above with those of the other peers

bryan-huang
2016-11-17 13:49
okay, let me check, thx

bryan-huang
2016-11-17 13:52
I c, I got the problem its caused by the chaincode

bryan-huang
2016-11-17 13:52
thx a lot

streich
2016-11-17 19:28
has joined #fabric-dev

vdods
2016-11-18 01:40
Hi all, how complete are the GRPC APIs and underlying functionality for the various components (e.g. membersrvc, peers)? My goal is to run a real peer network through a bunch of transactions to test chaincode (I already have unit tests which use MockStub) with user authentication. Ideally I would use HFC (node.js SDK) to drive this, but it appears that it's not feature-complete. So I'm trying to find the next level down. Is driving things using GRPC myself (say, from a Golang program) a good way to go?

vdods
2016-11-18 01:41
I'm looking to drive a peer network to do something like what the `asset_management_with_roles` example does.

vdods
2016-11-18 01:42
But I haven't found a complete end-to-end demonstration of this (for example, what the end-to-end.js unit test in node SDK would be)

ypqu
2016-11-18 08:31
has joined #fabric-dev

jpleboue
2016-11-18 20:44
has joined #fabric-dev

jpleboue
2016-11-18 20:46
Hey everyone, I'm part of a senior design team at NCSU and our project deals with blockchain and at its core, Hyperledger. We were wondering if anyone has ever deployed fabric onto a network of Raspberry Pis. Thanks for any responses.

ghaskins
2016-11-18 20:49
Hello @jpleboue, welcome. I seem to recall someone talking about that before, but I do not know what became of it. Right now I would guess there would be some basic challenges getting things compiled for ARM where they dont yet exist...we have support for x86_64, ppcle64 and s390x, and would welcome the addition of arm/pi if you wanted to help contribute to that

vdods
2016-11-18 22:18
Any comment on this? The GRPC thing I mentioned earlier? Anyone? Beuler?

ry
2016-11-19 11:14
@garisingh @kostas the fabric builds in jenkins are on go 1.7

ry
2016-11-19 11:14
I haven't brought forward all of the other builds yet, and I'm vacation next week, but fabric is there.

kostas
2016-11-19 14:29
@ry: Great news, thank you.

vdods
2016-11-19 19:35
I've got a change submitted to Gerrit which has a failure on one of the Jenkins build operations ( https://jenkins.hyperledger.org/job/fabric-verify-behave-x86_64/1821/ ) which has nothing to do with my changeset. Is there a way to kick the build or otherwise deal with this problem?

ramesh
2016-11-19 19:39
@vdods : re-triggered

vdods
2016-11-19 19:42
@ramesh Thanks -- interestingly, I just noticed that the line in the build log says `Patch Set 2: Verified+1 Build Successful https://jenkins.hyperledger.org/job/fabric-verify-behave-x86_64/1821/ : FAILURE (skipped) https://jenkins.hyperledger.org/job/fabric-verify-x86_64/2980/ : SUCCESS`

vdods
2016-11-19 19:42
so apparently one of these failures doesn't matter

ramesh
2016-11-19 19:42
We are skipping behave build result..

vdods
2016-11-19 19:43
Ah ok, gotcha.

yacovm
2016-11-19 19:43
Why are they running if they are skipped?

yacovm
2016-11-19 19:43
doesn't it consume resources?

ramesh
2016-11-19 19:48
Most of the behave tests are failing because of containers are not coming up with in specified time...Could be because of docker version 1.8.2 in Jenkins CI

ramesh
2016-11-19 19:50
also builds are failing with this error https://jira.hyperledger.org/browse/FAB-898

ry
2016-11-19 19:51
Ramesh: new fabric CI image has docker 1.12

ramesh
2016-11-19 19:53
yes @ry.. We are getting below error on new images ```Exception AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'```


ramesh
2016-11-19 19:55
observed this issue on new docker version

vdods
2016-11-19 20:20
Random question: Why Gerrit, and not Github?

garisingh
2016-11-19 21:32
@joequant - saw your post on the mailing list - if you want to use the v0.6 version of the fabric and build your own images, just checkout the v0.6 branch / tag

ghaskins
2016-11-20 15:48
@yacovm I keep getting a CI failure that seems to be unrelated to my changes: https://jenkins.hyperledger.org/job/fabric-verify-x86_64/3012/console

ghaskins
2016-11-20 15:48

yacovm
2016-11-20 15:49
that's core/comm

ghaskins
2016-11-20 15:49
know anything about that?

yacovm
2016-11-20 15:49
what do I have to do with it? :slightly_smiling_face:

ghaskins
2016-11-20 15:49
not sure, I either get gossip/state or this one

yacovm
2016-11-20 15:49
I'm gossip/* without gossip/state :wink:

ghaskins
2016-11-20 15:49
so I figured they were related

yacovm
2016-11-20 15:49
gossip/state? no way

yacovm
2016-11-20 15:49
I commented out the problematic tests there

ghaskins
2016-11-20 15:49
do we know who is working on either of those?

yacovm
2016-11-20 15:49
let me see who committed on github

yacovm
2016-11-20 15:50
the browser view shows you the last commit on the file

ghaskins
2016-11-20 15:50
what file?

yacovm
2016-11-20 15:50
`connection_test.go:40: error connection to server at host:port = localhost:7051`

yacovm
2016-11-20 15:50
That's the test file that is running


ghaskins
2016-11-20 15:51
ah, i think the only thing changed when was how the path was formed, but that all passed CI

ghaskins
2016-11-20 15:51
now it no longer passes CI

ghaskins
2016-11-20 15:52
anyway, sorry, I thought it was related to the rash of gossip failures

ghaskins
2016-11-20 15:52
not sure why nothing will pass right now

yacovm
2016-11-20 15:52
They sometimes pass

yacovm
2016-11-20 15:52
I mean the connection_test.go

ghaskins
2016-11-20 15:53
for whatever reason, https://gerrit.hyperledger.org/r/#/c/2307/ will not pass

ghaskins
2016-11-20 15:53
i seem to get either this one, or gossip/state failures

ghaskins
2016-11-20 15:53
feels like a timing problem

yacovm
2016-11-20 15:53
timed out?

ghaskins
2016-11-20 15:53
i think so, i dont recall

yacovm
2016-11-20 15:54
can you give me a link please?

ghaskins
2016-11-20 15:54
ill try to reverify

yacovm
2016-11-20 15:54
Ramesh had this on the merge CI job

yacovm
2016-11-20 15:54
is it on a merge job too?

ghaskins
2016-11-20 15:54
just walk though the V-1 history of 2307

yacovm
2016-11-20 15:55
don't see

yacovm
2016-11-20 15:55
can I get an example please?

ghaskins
2016-11-20 15:56
hmm, nevermind, in this case its always comm

ghaskins
2016-11-20 15:56
i am seeing the gossip/state one too, but in other CRs

yacovm
2016-11-20 15:57
From what I know there were 2 problematic tests, and I commented them out in a PR to make CI flow

ghaskins
2016-11-20 15:57
which CR was that?


ghaskins
2016-11-20 15:57
ill make sure I am rebased

ghaskins
2016-11-20 15:57
ty

ghaskins
2016-11-20 15:58
yeah, looks like I am on top of that now

ghaskins
2016-11-20 15:58
would that explain why the gossip/state one seems to have subsided?

ghaskins
2016-11-20 15:58
or was that a different failure?

yacovm
2016-11-20 15:58
of course

ghaskins
2016-11-20 15:58
ok

yacovm
2016-11-20 15:58
I don't know about other failures, if you encounter one, please tell me

ghaskins
2016-11-20 15:58
well, you made some comment earlier about gossip/* gossip/state

ghaskins
2016-11-20 15:59
ok...i was having problems with both gossip/state and comms, but it seems gossip/state has gone away for now

yacovm
2016-11-20 16:00
if it's comm it must be the testBlackList

yacovm
2016-11-20 16:00
I made a PR this morning that fixes it

ghaskins
2016-11-20 16:00
not merged yet?

yacovm
2016-11-20 16:00
and makes gossip/comm faster

yacovm
2016-11-20 16:00
nope


yacovm
2016-11-20 16:09
It happens pretty rarely btw, the gossip/comm failure.

yacovm
2016-11-20 16:20
The tests in core/comm pass on my machine, if that helps

ghaskins
2016-11-20 18:36
@yacovm I found the issue

ghaskins
2016-11-20 18:36
nothing to do with you

ghaskins
2016-11-20 18:37
@garisingh @muralisr we should revisit the decision to merge 2453 (https://gerrit.hyperledger.org/r/#/c/2453/)...it breaks any attempt to package/run the code unless the full source tree is present

ghaskins
2016-11-20 18:38
(which, I found out the hard way when I tried to clean up the included src ;)

ghaskins
2016-11-20 18:38
e.g. CR 2307

muralisr
2016-11-20 18:39
@ghaskins thinking…. :slightly_smiling_face:

ghaskins
2016-11-20 18:40
I am not against a separate .json file per se, but at the very least it should be somehow tied into the overall configuration mechanism

muralisr
2016-11-20 18:40
right

ghaskins
2016-11-20 18:41
fwiw, the decision to merge 2453 materializes like this https://jenkins.hyperledger.org/job/fabric-verify-x86_64/3012/console

ghaskins
2016-11-20 18:41
because the peer can no longer run unless the fabric src is present

ghaskins
2016-11-20 18:41
(and other assumptions surrounding that)

muralisr
2016-11-20 18:41
this has to do with the the bootstrap mechanisms https://jira.hyperledger.org/issues/?jql=text%20~%20%22bootstrap%22 which when in place can make this go away

muralisr
2016-11-20 18:42
hmmm

ghaskins
2016-11-20 18:43
I was so happy because master no longer required consensus/pbft/config.yaml :wink:

ghaskins
2016-11-20 18:43
and then this bit me

garisingh
2016-11-20 18:45
@ghaskins - just to be clear - you are saying that a peer binary will not run unless the source is there (or minimally that various config files are in the GOPATH)? This is of course not about unit tests, etc?

ghaskins
2016-11-20 18:46
correct

ghaskins
2016-11-20 18:47
the peer, as of the merge of CR 2453, now requires ../../msp/peer-config.json (and other things like that)

ghaskins
2016-11-20 18:47
which is....not right

ghaskins
2016-11-20 18:47
ideally, I can make a docker container that has just

ghaskins
2016-11-20 18:47

ghaskins
2016-11-20 18:48
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F35L5606S/-.pl and commented: or this, if the config has to be separate

ghaskins
2016-11-20 18:49
but the way 2453 is coded makes this, at best, awkward

ghaskins
2016-11-20 18:49
I could hack it with CWD tricks so ../../msp works, but that seems like hack on a hack :wink:

ghaskins
2016-11-20 18:50
thoughts?

ghaskins
2016-11-20 18:50
one thought, the peer currently uses PEER_CFG_PATH envvar to find core.yaml

ghaskins
2016-11-20 18:51
if the msp stuff used that too, it would work

ghaskins
2016-11-20 18:51
but someone should probably put some thought into what we want the configuration mechanism to actually look like in a production/deployed scenario, and not so ad-hoc

muralisr
2016-11-20 18:54
given that this is a temporary solution (based on the TODO above that line… ) how about something like this

adc
2016-11-20 18:55
The MSP configuration file may be included in some way in core.yaml if this helps

muralisr
2016-11-20 18:55
(1) embed the json inside main as a string and (2) look for a core.yaml param to the path

muralisr
2016-11-20 18:56
if the MSP is not defined in core.yaml, just use the embedded json in main

ghaskins
2016-11-20 18:56
@adc: that sounds ideal to me...I dont have a strong opinion on json vs yaml, but the notion that its one cohesive configuration solution is ideal to me

muralisr
2016-11-20 18:57
I think you’d need both (1) and the definition in core.yaml @adc ?

muralisr
2016-11-20 18:57
because the problem @ghaskins describes cannot be solved just by the definition in core.yaml

adc
2016-11-20 18:57
Is it possible to embed a json string in a yaml file?

muralisr
2016-11-20 18:58
or that

muralisr
2016-11-20 18:58
sure

adc
2016-11-20 18:58
That would be okay for the MSP

muralisr
2016-11-20 18:58
or have a separate msp-default.go

muralisr
2016-11-20 18:58
in main

ghaskins
2016-11-20 18:58
heres one thought: if multiple files are required/desired, we could we have one central definition of a global configuration root (e.g. PEER_CFG_PATH) and everything is expected to be relative to that _by default)

adc
2016-11-20 18:59
Sounds reasonable

ghaskins
2016-11-20 18:59
with core.yaml providing path overrides if that is desired

ghaskins
2016-11-20 19:00
e.g. default MSP path is CENTRAL_PATH/msp/peer-config.json, but you can also set core.yaml -> msp.peer-config.path to whatever you want

muralisr
2016-11-20 19:00
would that work for the current problem ? …

ghaskins
2016-11-20 19:01
I dont know enough about MSP to say whether it makes sense to embed the elements directly in core.yaml or not

ghaskins
2016-11-20 19:01
yes, I think both solutions would work for me

adc
2016-11-20 19:01
From the MSP perspective that's irrelevant

ghaskins
2016-11-20 19:01
(embedding in core.yaml, or the central-config thing)

adc
2016-11-20 19:02
It only needs to be configured in some way. Right now, it only accepts a json-based configuration

ghaskins
2016-11-20 19:02
is this a third party component?

adc
2016-11-20 19:02
It might be used also in that way

ghaskins
2016-11-20 19:02
e.g. we didnt code the json requirement?

adc
2016-11-20 19:03
Like the bccsp

ghaskins
2016-11-20 19:03
or is it our code and it could be adapted to the fabric-general config solution

adc
2016-11-20 19:03
It's our code. We can adapt

ghaskins
2016-11-20 19:03
ok...it seems to be (speaking in relative ignorance of the requirements for MSP) that this would be preferred

ghaskins
2016-11-20 19:04
just make them yaml keys, or, embed json strings if need be

ghaskins
2016-11-20 19:04
and keep the configuration in one place and simple

ghaskins
2016-11-20 19:05
from a packaging perspective, this would be my preference

ghaskins
2016-11-20 19:05
but I can be convinced otherwise if multi-files are a hard requirement

adc
2016-11-20 19:06
Using yaml keys would require a modification of the MSP. Changing the config file configuration does not require any change. To be setup the MSP takes in input a json string with all the properties to configure the MSP itself

ghaskins
2016-11-20 19:06
the only thing that makes me nervous is I think we need some notion of relative path

muralisr
2016-11-20 19:07
right. That’s why I was thinking an embedded default

ghaskins
2016-11-20 19:07
e.g. putting "core.msp.config-path = blah" in the yaml would be hard to maintain too

muralisr
2016-11-20 19:07
especially if this is temporary

ghaskins
2016-11-20 19:07
i think either way, the code would have to change

ghaskins
2016-11-20 19:08
its purely a question of how much and where

ghaskins
2016-11-20 19:08
right now this is not good...i would have -1 it if I had been paying close enough attention :wink:

garisingh
2016-11-20 19:08
hang on folks - we can't have every piece of config in the same file this is not that hard - we can have properties in core.yaml which specific the absolute paths to config files. I think that's the best way to go. You can always override those via environment variables when running unit tests

ghaskins
2016-11-20 19:09
@garisingh not against multi files, but I still suggest a relative file default

garisingh
2016-11-20 19:09
sure

garisingh
2016-11-20 19:09
I concur with that

ghaskins
2016-11-20 19:09
ROOT/peer/core.yaml, ROOT/msp/peer-config.json, etc

ghaskins
2016-11-20 19:09
cool

ghaskins
2016-11-20 19:10
I think that will be the most flexible

ghaskins
2016-11-20 19:10
without being a PITA

garisingh
2016-11-20 19:10
I always hated the use of GOPATH for file lookup.

garisingh
2016-11-20 19:11
not sure who dreamed that one up :wink:

ghaskins
2016-11-20 19:11
yeah, I think CWD is a safer default

ghaskins
2016-11-20 19:11
optionally CWD first, /etc/hyperledger/fabric second, or overridden by a switch/envvar

adc
2016-11-20 19:11
What's CWD? Sorry :(

ghaskins
2016-11-20 19:11
current working dir

adc
2016-11-20 19:11
Thanks

ghaskins
2016-11-20 19:12
so, who is going to put this in ?

ghaskins
2016-11-20 19:12
:wink:

muralisr
2016-11-20 19:12
I can unless @adc wants to :slightly_smiling_face:

adc
2016-11-20 19:12
The MSP is fine with that. Only the code to load the config file has to be changed and that code is external to the MSP

adc
2016-11-20 19:12
@muralisr: please go ahead :)

ghaskins
2016-11-20 19:12
cool, thanks all

ghaskins
2016-11-20 19:12
i have to step away again

muralisr
2016-11-20 19:13
so use CWD ?

ghaskins
2016-11-20 19:13
@muralisr I think all that needs to be done is perhaps enhance the current PEER_CFG_PATH thing

ghaskins
2016-11-20 19:13
make it so the selected path is a globally accessible value

ghaskins
2016-11-20 19:13
drive that with CWD by default, overridden by PEER_CFG_PATH, etc

ghaskins
2016-11-20 19:14
and then make all the right places (core.yaml, msp/peer-config.json, etc) use that global

ghaskins
2016-11-20 19:15
something like that

muralisr
2016-11-20 19:15
how about we try this only for the current problem ?

muralisr
2016-11-20 19:15
I’m worried this will become a large excavation

ghaskins
2016-11-20 19:16
if its at least coupled with PEER_CFG_PATH and core.yaml, that makes my life easier

ghaskins
2016-11-20 19:16
but I also think this is going to be the only place

ghaskins
2016-11-20 19:16
my docker images all worked earlier in the week

ghaskins
2016-11-20 19:16
all of a sudden they went to hell after 2453

ghaskins
2016-11-20 19:16
so, that implies that we only need core.yaml and peer-config.json

ghaskins
2016-11-20 19:17
(unless msp added others)

muralisr
2016-11-20 19:17
sorry …. I’m likely dense :slightly_smiling_face: but why do we want to change core.yaml ?

muralisr
2016-11-20 19:17
if that was working before

ghaskins
2016-11-20 19:17
no no, i mean integrate the solution for msp such that its cohesive with core/PEER_CFG_PATH

ghaskins
2016-11-20 19:17
not that there are any changes to core.yaml

ghaskins
2016-11-20 19:17
i mean, dont create a one-off for MSP

ghaskins
2016-11-20 19:19
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F352NDJHJ/-.sh and commented: The ideal solution would more or less work with minimal changes to this Dockerfile

ghaskins
2016-11-20 19:19
I think line 6 would change to COPY payload/config.tar.bz $PEER_CFG_PATH

ghaskins
2016-11-20 19:19
and thats it

ghaskins
2016-11-20 19:19
I am open to other suggestions though

ghaskins
2016-11-20 19:21
what I am getting at is, I would avoid having something orthogonal like MSP_CFG_PATH introduced

ghaskins
2016-11-20 19:21
thats all

ghaskins
2016-11-20 19:21
but I am open

muralisr
2016-11-20 19:28
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F34TVJ8E7/pasted_image_at_2016_11_20_02_28_pm.png and commented: where are we currently setting or using PEER_CFG_PATH ?

muralisr
2016-11-20 19:40
@ghaskins I see its used in your changeset

ghaskins
2016-11-20 19:41
I use it in docker, for one

ghaskins
2016-11-20 19:41
Right, otherwise I don't know if anyone uses it

muralisr
2016-11-20 19:42
understand now

muralisr
2016-11-20 19:42
sorry took me a while :slightly_smiling_face:

muralisr
2016-11-20 19:46
@ghaskins how about this


muralisr
2016-11-20 19:55
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F34A3HTTK/pasted_image_at_2016_11_20_02_55_pm.png and commented: or even safer @ghaskins …

muralisr
2016-11-20 20:01

muralisr
2016-11-20 20:02
will submit above fix against that for review

yacovm
2016-11-20 20:05
Of course it has nothing to do with me, that's in a different package. What was the issue though?

yacovm
2016-11-20 20:05
@ghaskins

muralisr
2016-11-20 20:16
@yacovm I think @ghaskins had to step out for a bit… the problem was that anytime we assume full peer environment to be there (such as `os.Getenv("GOPATH") + "/src/github.com/hyperledger/fabric/msp/peer-config.json`) we prevent other environments that don’t have the full fabric from working

muralisr
2016-11-20 20:16
GOPATH implies “GO” environment implies full fabric typically

muralisr
2016-11-20 20:18
we will follow other use of PEER_CFG_PATH to break that implied strong assoication with a full fabric path

yacovm
2016-11-20 20:29
ok

ghaskins
2016-11-20 20:37
Sorry @yacovm what I meant was that I confirmed it

ghaskins
2016-11-20 20:37
Just updating status

ghaskins
2016-11-20 20:38
I know we more or less knew that, just closing it out

ghaskins
2016-11-20 20:39
@muralisr: on mobile but fix looks good from here

muralisr
2016-11-20 20:39
@ghaskins thanks. testing it . Will push it out soon

muralisr
2016-11-20 21:57
@ghaskins @garisingh submitted https://gerrit.hyperledger.org/r/#/c/2653

vdods
2016-11-21 00:57
I've dockerized a unit test from sdk/node (with the peer running in network mode) and find that the peer leaves the chaincode docker container exited even after I quit the peer. Is there something explicit I have to do to have it remove the exited chaincode container?

ghaskins
2016-11-21 02:26
@muralisr seems to work fine...though there is one oddity

ghaskins
2016-11-21 02:27
the core.yaml config treats PEER_CFG_PATH as relative to fabric.git/peer whereas the peer-config.json treats it as relative to fabric.git/

ghaskins
2016-11-21 02:28
its not a huge deal, I worked around it in the Dockerfile by placing the files as /etc/hyperledger/fabric/core.yaml and /etc/hyperledger/fabric/msp/peer-config.json

matpasha
2016-11-21 07:01
Hi , We are running fabric in prod mode which requires the git repo path at the time of chaincode deployment. Currently we are unable to deploy the code from a private git repo. Is there a way around this? Could anybody please help on this issue? Thanks

garisingh
2016-11-21 11:12
@matpasha - you can't deploy directly from a private git repo but you can deploy directly from a local machine using the SDK(s) and/or the peer CLI. Of course this means you must first clone the git repo locally (well at least onto a machine you have access to)

matpasha
2016-11-21 11:16
@garisingh Yes thanks I was able to deploy from a local path by attaching volumes in docker to contain the chaincode and deploying it from a local path.

oiakovlev
2016-11-21 12:03
Hi, when I try to run `asset_managment02_test.go` locally I got the following error: ``` # http://github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb ../../../../vendor/github.com/tecbot/gorocksdb/backup.go:4:24: fatal error: rocksdb/c.h: No such file or directory // #include "rocksdb/c.h" ^ compilation terminated. ``` I'm running on Ubuntu 16.04 and have not installed RocksDB - do I have to? What else could be missed? Is there any description exists how to run such tests...? Other tests work fine for me...

oiakovlev
2016-11-21 12:04
I run test from ide and it is executed with the following command: `/opt/go/go/bin/go test -v http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management02 -bench . -run ^$`

garisingh
2016-11-21 12:20
@oiakovlev - yes - for `asset_management02` and `asset_management_with_roles` if you are going to run the tests you need to have RocksDB installed. The tests for both of these start up an "embedded" instance of the peer in order for the test(s) to run. Are you running these in master or another branch?

oiakovlev
2016-11-21 12:20
v06

oiakovlev
2016-11-21 12:20
sorry for non specifying this

oiakovlev
2016-11-21 13:02
should I add any env variables to the test execution? - if I downloaded and unpacked RocksDB under opt, then successfully run `make static_lib`... following https://github.com/facebook/rocksdb/blob/master/INSTALL.md

garisingh
2016-11-21 13:07
just make sure that you actually checkout the 4.1 tag and don't build the latest version

oiakovlev
2016-11-21 13:09
ok, now have to uninstall.. but it have: `RUN cd /opt && git clone --branch v4.1 --single-branch --depth 1 https://github.com/facebook/rocksdb.git && cd rocksdb`

oiakovlev
2016-11-21 13:10
is it a requirement to install it under /opt? or can I install it under `/opt/hyperledger/rocksdb` for example?

garisingh
2016-11-21 13:14
no requirement where to install as long as it can be found

garisingh
2016-11-21 13:15
so you might have to add it your LD_LIBRARY_PATH

oiakovlev
2016-11-21 14:22
Now I got: ``` Wait for some secs for OBCCA 16:18:54.763 [ca] NewCA -> INFO 001 Fresh start; creating databases, key pairs, and certificates. Wait for some secs for VP 16:18:56.764 [crypto] RegisterValidator -> INFO 002 Registering validator [vp] with name [vp]... 16:18:56.768 [crypto] Errorf -> ERRO 003 [validator.vp] Failed requesting read certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 16:18:56.768 [crypto] Errorf -> ERRO 004 [validator.vp] Failed requesting ECA certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 16:18:56.768 [crypto] Errorf -> ERRO 005 [validator.vp] Failed getting ECA certificate [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 16:18:56.768 [crypto] Errorf -> ERRO 006 [validator.vp] Failed retrieving ECA certs chain [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 2016/11/21 16:18:56 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:7054: getsockopt: connection refused"; Reconnecting to {"localhost:7054" <nil>} 2016/11/21 16:18:56 Failed to dial localhost:7054: grpc: the connection is closing; please retry. 16:18:56.768 [crypto] Errorf -> ERRO 007 [validator.vp] Failed registering node crypto engine [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. 16:18:56.768 [crypto] Errorf -> ERRO 008 [validator.vp] Failed registering peer [vp]: [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure] 16:18:56.768 [crypto] Errorf -> ERRO 009 [validator.vp] Failed registering [vp]: [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure] 16:18:56.768 [crypto] RegisterValidator -> ERRO 00a Failed registering validator [vp] with name [vp] [rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure]. panic: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure goroutine 25 [running]: panic(0xb02100, 0xc42037c700) /opt/go/go/src/runtime/panic.go:500 +0x1a1 http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management02.initVP() /home/oleg/Development/Go/src/github.com/hyperledger/fabric/examples/chaincode/go/asset_management02/asset_management02_test.go:608 +0x541 created by http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management02.TestMain /home/oleg/Development/Go/src/github.com/hyperledger/fabric/examples/chaincode/go/asset_management02/asset_management02_test.go:75 +0xfd exit status 2 FAIL http://github.com/hyperledger/fabric/examples/chaincode/go/asset_management02 2.034s ``` I'm exporting: `export LD_LIBRARY_PATH=/opt/rocksdb:$LD_LIBRARY_PATH` and running as: `CGO_CFLAGS="-I/opt/rocksdb/include" CGO_LDFLAGS="-L/opt/rocksdb -lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" go test `

oiakovlev
2016-11-21 14:29
so just what I try to achieve is to test the code, which uses `ok, err := stub.InsertRow(...)` and when I use mock `stub := shim.NewMockStub` insertRow fails - I guess it is not mocked. Any option to test it without running peers and so on?

oiakovlev
2016-11-21 14:38
ah yes...: ``` // Not implemented func (stub *MockStub) InsertRow(tableName string, row Row) (bool, error) { return false, nil } ```

muralisr
2016-11-21 15:09
@ghaskins `the core.yaml config treats PEER_CFG_PATH as relative to fabric.git/peer whereas the peer-config.json treats it as relative to fabric.git/` …. right. Seemed more natural for PEER_CFG_PATH to point to a “core” root than `peer` as there are other dirs whose config may belong outside of `peer`

muralisr
2016-11-21 15:10
(a bit late with the ^^^ observation :slightly_smiling_face: …apologize)

ghaskins
2016-11-21 15:18
@muralisr after thinking about it some more, things might be optimal as they are

ghaskins
2016-11-21 15:18
its a little awkward that the topology is different if you are using PEER_CFG_PATH vs GOPATH, but in some ways this makes sense

ghaskins
2016-11-21 15:19
e.g. what makes sense from a config topology (PEER_CFG_PATH) might not make sense from a code topology (GOPATH)

ghaskins
2016-11-21 15:19
the asymmetry initially bothered my sensibilities, but after more thought, perhaps we just leave it

ghaskins
2016-11-21 15:20
for instance, we dont want to propose peer/core.yaml should be moved to ../ because then its confusing between peer and orderer

ghaskins
2016-11-21 15:21
and likewise, we probably dont want to propose to move ./msp to ./peer/msp, because that might not be appropriate

ghaskins
2016-11-21 15:21
thoughts?

muralisr
2016-11-21 15:25
@ghaskins right, that’s exactly my thoughts too. Makes sense to have PEER_CFG_PATH be a “root” path of which any other config params such as for `peer` or `msp` .. and others in in future... to hang off ?

ghaskins
2016-11-21 15:28
ok, but note its not _quite_ like that today

ghaskins
2016-11-21 15:28
we could fix this

ghaskins
2016-11-21 15:28
the code currently assumes the core.yaml will be found at $PEER_CFG_PATH/core.yaml

ghaskins
2016-11-21 15:28
do we want to change this so its $PEER_CFG_PATH/peer/core.yaml ?

ghaskins
2016-11-21 15:29
that would provide asymmetry

muralisr
2016-11-21 15:32
right

muralisr
2016-11-21 15:33
I think that’s better. I assume the workaround you used was to create msp under peer ?

muralisr
2016-11-21 15:34
but yes I think `$PEER_CFG_PATH/peer/core.yaml` sounds right to me

simon
2016-11-21 15:39
yey CI failures

simon
2016-11-21 15:39
something in chaincode

ramesh
2016-11-21 15:56

aso
2016-11-21 16:26
I think it's related to the fact that they take too long ``` test timed out after 20m0s ```

muralisr
2016-11-21 16:28
@ramesh can you try it on your vagrant now ? wonder if its a network thing

ramesh
2016-11-21 16:32
seems it's working now in CI (Jenkins).. @muralisr will re-run tests in vagrant

tuand
2016-11-21 17:04
what changed with the build of hyperledger/fabric-orderer ? orderer.yaml is in `etc/hyperledger/fabric` which is not one of the paths that orderer searches for its config file ...

tuand
2016-11-21 17:04
I can fix this easily enough in the orderer code but is there some other work going on that fixes this ?

ghaskins
2016-11-21 18:17
@tuand sounds like the work I am doing

ghaskins
2016-11-21 18:17
I did notice that both orderer and membersrvc (when it existed) were weak w.r.t. config path...so in the case of those components, I worked around it with a WORKDIR specification

ghaskins
2016-11-21 18:18

ghaskins
2016-11-21 18:18
see line 5

ghaskins
2016-11-21 18:19
I would welcome a "PEER_CFG_PATH" type mod to orderer so I dont need to hack the WORKDIR anymore

tuand
2016-11-21 18:26
interesting ... if i go into the orderer container via `docker exec -it /bin/bash` and start the orderer then the code finds the yaml file just fine

tuand
2016-11-21 18:27
but if I start via the bddtests `docker-compose -f docker-compose-orderer-solo.yml up` then orderer does not find the yaml file

tuand
2016-11-21 18:28
I can look at peer_cfg_path ... can you point me to the changeset ?

jamesjong
2016-11-21 19:25
has joined #fabric-dev

ghaskins
2016-11-21 19:30
Check for any WORKDIR statements in the compose files bdd is using

tuand
2016-11-21 19:38

ghaskins
2016-11-21 19:44
Looks good from the phone. I'll review fully when back at my desk

jkilpatr
2016-11-21 20:55
ghaskins got peer working on a centos based fabric base image

ghaskins
2016-11-21 20:55
cool

jkilpatr
2016-11-21 20:55
easier than I expected once I got a day to work on it and had any idea what I was doing

ghaskins
2016-11-21 20:56
yeah, its not too bad on modern distro

ghaskins
2016-11-21 20:56
biggest PITA is usually rocksdb

jkilpatr
2016-11-21 20:56
ghaskins the bash used for rocksdb setup in the baseimage automaton worked fine no tweaking at all

ghaskins
2016-11-21 20:56
cool

jkilpatr
2016-11-21 20:56
all I did there was convert apt to yum and a few other bits

ghaskins
2016-11-21 20:56
yep, makes sense


jkilpatr
2016-11-21 20:58
that's really it for the base image, then peer is just a library path added to its docker file env. Other components are in progress but probably going to be slow, don't get much time for hyperledger.

jkilpatr
2016-11-21 20:58
how would you like me to structure multi os support in this tooling if I contributed it upstream?

ghaskins
2016-11-21 20:59
im not sure, id have to think about whether it makes sense to do it this way

ghaskins
2016-11-21 21:00
btw: it looks like you had an overzealous s/-j/-j24 conversion :wink:

ghaskins
2016-11-21 21:00
let me give it some thought

jkilpatr
2016-11-21 21:02
building rocksdb is annoying, moved it to a machine with more POWA

as93717913
2016-11-22 03:52
has joined #fabric-dev

jpleboue
2016-11-22 05:39
Hey again, I asked about implementing fabric onto a Raspberry Pi a couple of days ago, and ghaskins suggested I build support for the ARM architechture. Would anyone know where I could start in the development of this? Thank you

simon
2016-11-22 10:12
so why is nobody fixing the test failures?

simon
2016-11-22 10:12
for days or weeks there are pieces in the code that fail

jonathanlevi
2016-11-22 10:27
@simon: weeks :disappointed:

simon
2016-11-22 10:27
so either change gerrit so that failures don't block merges

simon
2016-11-22 10:27
or fix your failing tests

jonathanlevi
2016-11-22 10:28
Yup. We should not merge anything to a broken `branch`. If you ask me.

jonathanlevi
2016-11-22 10:28
We can define broken as any build failing.

simon
2016-11-22 10:28
no that's not the problem

simon
2016-11-22 10:28
fix your broken tests

simon
2016-11-22 10:29
have some responsibility for your own code

jonathanlevi
2016-11-22 10:29
Amen to that. That’s if we assume/expect each and every contributor to proactively support his stuff.

jonathanlevi
2016-11-22 10:30
I’m trying to also think of what we can do, to prevent such ongoing cases of broken or even needing to support “them non-deterministic tests”, if you recall.

jonathanlevi
2016-11-22 10:30
We should probably complement your suggestion with a policy for the “code guards”.

simon
2016-11-22 10:30
well, i spent half a year to rewrite the code so that the tests can be deterministic

jonathanlevi
2016-11-22 10:30
I know, I know!

jonathanlevi
2016-11-22 10:31
If you recall we have a few branches that would not build in October and in September.

jonathanlevi
2016-11-22 10:32
At some point, I felt like “reverting” offending code… but then we started all converging back to master, so most of these got addressed. Most, I have to say.

jonathanlevi
2016-11-22 10:33
It’s still painful (especially as some of these tests are so slowwwwwww)

yacovm
2016-11-22 10:34
Right now CI is broken

yacovm
2016-11-22 10:35
I think the CI minions are dead or something, I tagged people in #ci-pipeline

simon
2016-11-22 10:36
yacovm: there is a problem in gossip

yacovm
2016-11-22 10:36
what problem?


yacovm
2016-11-22 10:40
Do you know if there is a way to access the code of the test there? It doesn't look up to date @simon

simon
2016-11-22 10:40
i don't know

simon
2016-11-22 10:40
what do you mean, up to date

yacovm
2016-11-22 10:41
I mean- that stack trace is a symptom of code that I fixed

yacovm
2016-11-22 10:41
I remember the very line numbers

yacovm
2016-11-22 10:42
and the error (send on closed channel) should not be received because that channel doesn't close now

yacovm
2016-11-22 10:42
I submitted the PR that fixes it myself

jonathanlevi
2016-11-22 10:42
Yes, I remember that.

simon
2016-11-22 10:42
when has that been merged?

jonathanlevi
2016-11-22 10:42
Yup

yacovm
2016-11-22 10:42
last week,

yacovm
2016-11-22 10:43
I think?

jonathanlevi
2016-11-22 10:43
Indeed.

simon
2016-11-22 10:43
wat

simon
2016-11-22 10:43
i did rebases

yacovm
2016-11-22 10:44
I think CI is acting weird, Ramesh opened a JIRA issue to me this sunday about a test failing in gossip, and this test was commented out by a PR of mine- so it should never have failed in Ramesh's CI job because, well... it was commented out in master.

yacovm
2016-11-22 10:45
(remember that time last week you submitted ?BFT and complained that the tests fail? I submitted a PR that comments the faulty tests on that very day https://gerrit.hyperledger.org/r/#/c/2575/)

yacovm
2016-11-22 10:46
oh found it

yacovm
2016-11-22 10:47
this failure you just showed, was supposed to be fixed by: https://gerrit.hyperledger.org/r/#/c/2505/

yacovm
2016-11-22 10:50

simon
2016-11-22 10:58
then something in the gerrit rebase didn't work

c0rwin
2016-11-22 11:05
something doesn’t make sense for me, since in trace here: https://jenkins.hyperledger.org/job/fabric-verify-x86_64/3061/console

c0rwin
2016-11-22 11:05
```11:45:28 11:45:28 goroutine 606 [running]: 11:45:28 panic(0x961460, 0xc421390c60) 11:45:28 /opt/go/go1.7.linux.amd64/src/runtime/panic.go:500 +0x1a1 11:45:28 http://github.com/hyperledger/fabric/gossip/state.waitUntilTrueOrTimeout.func1(0xc420a8e4d8, 0xc420a8e710, 0xc42136ac00) 11:45:28 /w/workspace/fabric-verify-x86_64/gopath/src/github.com/hyperledger/fabric/gossip/state/state_test.go:334 +0x216 11:45:28 created by http://github.com/hyperledger/fabric/gossip/state.waitUntilTrueOrTimeout 11:45:28 /w/workspace/fabric-verify-x86_64/gopath/src/github.com/hyperledger/fabric/gossip/state/state_test.go:338 +0xd0 11:45:28 FAIL http://github.com/hyperledger/fabric/gossip/state 56.359s 11:45:28 error: exit status 1 11:45:28 panic: EOF```

simon
2016-11-22 11:05
well allegedly it is fixed

c0rwin
2016-11-22 11:05
it refers to lines which doesn’t really exists

simon
2016-11-22 11:06
different code


c0rwin
2016-11-22 11:06
different code? how?

c0rwin
2016-11-22 11:06
didn’t you rebased?

yacovm
2016-11-22 11:06
That's what I'm saying. The code that was running in jenkins is different than the real code

yacovm
2016-11-22 11:57
@simon can you verify my PRs too? :wink:

simon
2016-11-22 11:57
what do you mean

yacovm
2016-11-22 11:58
Jenkins is broken

yacovm
2016-11-22 11:58
so I see you're +1 in its stead?

simon
2016-11-22 12:00
well, you can +1 yours as well

yacovm
2016-11-22 12:00
Instead of jenkins?

simon
2016-11-22 12:00
in addition

yacovm
2016-11-22 12:00
I'm simply trying to say- how are your PRs merged now when Jenkins is broken?

yacovm
2016-11-22 12:01
Isn't it risky?

c0rwin
2016-11-22 12:01
isn’t that a requirement to pass CI blessing before anyone can actually +2 and merge CR? :face_with_rolling_eyes:

yacovm
2016-11-22 12:01
Yeah, this :arrow_up:

simon
2016-11-22 12:02
why?

simon
2016-11-22 12:02
+2 is a different dimension from verify

jonathanlevi
2016-11-22 12:02
I believe we should not merge things when the build is broken.

jonathanlevi
2016-11-22 12:03
(whether it is the code or the CI)

simon
2016-11-22 12:03
i agree

simon
2016-11-22 12:03
we also shouldn't write any code

jonathanlevi
2016-11-22 12:03
We did it manually for v0.6, because we did not have a choice.

simon
2016-11-22 12:03
except for fixing the bug

jonathanlevi
2016-11-22 12:03
WDYM?

jonathanlevi
2016-11-22 12:04
People can submit PRs, etc… but usually it is difficult to later on find out what’s going on.

jonathanlevi
2016-11-22 12:04
(Again, on average, in the long run - it is not good practice)

simon
2016-11-22 12:04
yes

simon
2016-11-22 12:04
but as a concept

simon
2016-11-22 12:04
stuff is broken - stop everything, fix what is broken


c0rwin
2016-11-22 12:04
how +2 is a different dimension from CI verification? no one is expected to merge staff before it actually got verified

jonathanlevi
2016-11-22 12:05
@yacovm I didn’t say that we practice/enforce that policy/concept religiously.

jonathanlevi
2016-11-22 12:06
I’m trying to reach a consensus and possibly change the policy going forward (the more “stable” master gets)

jonathanlevi
2016-11-22 12:06
[As a follow up to Simon’s comments about tests/branch being broken for a while]

c0rwin
2016-11-22 12:07
if you one can override +1 verification step w/ +2, so what is the point in CI?

simon
2016-11-22 12:07
you cannot

jonathanlevi
2016-11-22 12:08
@c0rwin: good point. I was happy to override the verification step, say, when someone has changed a README file (after I have been a pain for a few iterations, and they really need the latest merged]

jonathanlevi
2016-11-22 12:08
But we should not (really) do so either.

simon
2016-11-22 12:08
this project is full of process

simon
2016-11-22 12:08
and process quells responsibility

jonathanlevi
2016-11-22 12:11
@c0rwin has a point, and I agree with @simon (I, too, expect contributors to take care of their code/tests when stuff is broken!)


yacovm
2016-11-22 12:12
What do you mean you cannot? You just did :arrow_up:

simon
2016-11-22 12:12
how is that overriding?

simon
2016-11-22 12:12
the +2 does not override the verified

simon
2016-11-22 12:12
the code review is independent of the verified

jonathanlevi
2016-11-22 12:13
I believe we need to strike the right balance between working under the `incubation` status - where we are OK with a few of us being `cowboys` at times.

jonathanlevi
2016-11-22 12:13
I believe it’s a matter of what makes the code better.

c0rwin
2016-11-22 12:13
but how that possible that one could +1 instead of CI and got CR merged?

jonathanlevi
2016-11-22 12:13
Too restrictive, will be a problem. Too lenient will keep the mess.

simon
2016-11-22 12:13
well i run the code locally, test passes, therefore i can +1 verified it

c0rwin
2016-11-22 12:14
Oh

c0rwin
2016-11-22 12:14
So my tests also runs locally

jonathanlevi
2016-11-22 12:14
@c0rwin Oh, that’s what you are asking. Yes, physically, we `can` do it.

yacovm
2016-11-22 12:14
who is we?

yacovm
2016-11-22 12:14
I don't think I can

simon
2016-11-22 12:14
you're not a maintainer then

yacovm
2016-11-22 12:14
aha!

c0rwin
2016-11-22 12:15
but there is definitely something wrong with them on CI and this is the reason we commented them out to take closer look

simon
2016-11-22 12:15
them who?

c0rwin
2016-11-22 12:15
them == my gossip state tests

simon
2016-11-22 12:15
ah no, i'm talking about my tests

simon
2016-11-22 12:16
that's the whole thing, that existing tests fail

c0rwin
2016-11-22 12:16
I understand

c0rwin
2016-11-22 12:16
and my point

c0rwin
2016-11-22 12:16
is that indication of your tests passed on you laptop has nothing to do w/ CI

c0rwin
2016-11-22 12:16
and not an indication for real

yacovm
2016-11-22 12:16
yeah, maybe (for example) you have a really strong laptop with SSD and tests that may pass locally will fail on CI

simon
2016-11-22 12:17
well clearly CI tests passing doesn't indicate anything either

simon
2016-11-22 12:17
because one time CI passes, another time it fails

c0rwin
2016-11-22 12:17
it’s more reliable than you local setup

simon
2016-11-22 12:17
clearly not

c0rwin
2016-11-22 12:17
k

simon
2016-11-22 12:17
how come broken code/tests made it into the repo?

yacovm
2016-11-22 12:18
The tests are not reliable, not the CI, unless the CI fails with a java jenkins strack trace

yacovm
2016-11-22 12:25
And if tests are unreliable they just need to be fixed or commented out and polished locally and then returned to the master branch

jonathanlevi
2016-11-22 12:27
If you guys want, we can put together a proposal for a more strict process.

jonathanlevi
2016-11-22 12:27
That is, if we all agree that the CI results “overrules” everything - then in case of an issue, we stop everything and fix it.

jonathanlevi
2016-11-22 12:28
But as long as we have flaky tests (in any part of the project), it is very difficult to enforce a/such policy.

jonathanlevi
2016-11-22 12:29
That’s why some of us/we (@yacovm: we == the maintainers) sometimes allow stuff into the branch, without triple-checking it.

simon
2016-11-22 12:29
please no automatic enforcement

jonathanlevi
2016-11-22 12:29
Yes, @simon, I hear you.

simon
2016-11-22 12:29
it just allows you to be sloppy

jonathanlevi
2016-11-22 12:30
But I also understand where @c0rwin is coming from… if you see what I mean?

simon
2016-11-22 12:30
no i don't get his point

yacovm
2016-11-22 12:30
But, what is going on now is *not* because of flaky tests, it's because of CI being *dead*

simon
2016-11-22 12:30
ah yea CI now is not running at all?

jonathanlevi
2016-11-22 12:31
I’m not talking about just now @yacovm. I’m talking about the point that @c0rwin has raised.

yacovm
2016-11-22 12:31
I told you it's not

jonathanlevi
2016-11-22 12:31
Yes, the CI now is super weird. I have “reverify”ied an hour or so… with not help.

yacovm
2016-11-22 12:31
I complained in #ci-pipeline I don't really know what else can be done https://jenkins.hyperledger.org/job/fabric-verify-x86_64/

jonathanlevi
2016-11-22 12:32
AFAIK, the CI “guys” are in a different timezone (PDT) though they start early.

jonathanlevi
2016-11-22 12:32
Give it a few hours…

garisingh
2016-11-22 12:42
actually I believe @ry is on vacation this week - not sure who his backup is? maybe @ramesh

yacovm
2016-11-22 12:43
I tagged both him and bramwelt

jonathanlevi
2016-11-22 12:47
Will try to “escalate”, too, in a bit.

garisingh
2016-11-22 12:48
BTW - related question - I know we run CI when change sets are pushed - but do we actually run the build on master every time we merge commits?

yacovm
2016-11-22 12:49
yeah

yacovm
2016-11-22 12:49
there is another type of job in jenkins

yacovm
2016-11-22 12:49
fabric-merge

yacovm
2016-11-22 12:49
something like that


garisingh
2016-11-22 13:08
ah - right - ok

ghaskins
2016-11-22 13:19
one problem I see is that very little attention is paid to the -merge jobs

ghaskins
2016-11-22 13:20
everyone notices the -verify jobs because their CR wont be merged until it passes

ghaskins
2016-11-22 13:20
but then the CR gets merged, and often times, the -merge job fails

ghaskins
2016-11-22 13:20
(not because the CR broke it per se, but just because of the flakiness

jonathanlevi
2016-11-22 13:21
True.

jonathanlevi
2016-11-22 13:22
Maybe we should be able to somehow flag that ?

jonathanlevi
2016-11-22 13:23
I used to work with systems that auto-reverts a broken merge.

jonathanlevi
2016-11-22 13:23
We won’t be able to miss that ;-)… but I wonder whether it’s too complex to implement.

garisingh
2016-11-22 13:25
@ghaskins - what are the typical causes of the flakiness?

yacovm
2016-11-22 13:26
I think there is a bug there in the merge jobs, because *I was opened* a JIRA issue about a gossip test that fails, even though that test wasn't supposed to exist at the time of the merge

garisingh
2016-11-22 13:26
I would also say that we should consider re-running CI merge jobs as well

simon
2016-11-22 13:27
i don't understand the diference

garisingh
2016-11-22 13:27
@simon - which difference?

simon
2016-11-22 13:28
between verify and merge jobs

ghaskins
2016-11-22 13:28
@garisingh I get the impression its a revolving door of issues

yacovm
2016-11-22 13:28
Difference is- merge job runs after the master has changed

ghaskins
2016-11-22 13:28
new flakiness introduced, old flakiness eventually getting fixed/removed

garisingh
2016-11-22 13:28
verify is run when you submit an change set - merge runs after a maintainer merges the commit

ghaskins
2016-11-22 13:28
sometimes I think its the CI platform is a little slow

garisingh
2016-11-22 13:29
certainly for all the $$$ people pay to HL we can get some decent machines for these jobs if that's the issue

ghaskins
2016-11-22 13:29
for instance, one source I have been seeing in the last week is that the chaincode tests take 19.5 - 20.5 minutes, and there is a 20m timeout

simon
2016-11-22 13:29
shouldn't the ci run on the commit that would happen if you merged?

ghaskins
2016-11-22 13:29
so sometimes it squeaks by, and sometimes it fails

garisingh
2016-11-22 13:29
@simon - it does

simon
2016-11-22 13:30
so why does it have to run again?

simon
2016-11-22 13:30
also, 20 minutes for chaincode tests?

ghaskins
2016-11-22 13:30
yes, we need to address that

ghaskins
2016-11-22 13:30
I am of the opinion that UTs in general should be fast

simon
2016-11-22 13:30
yes

ghaskins
2016-11-22 13:30
like, < 5 mins

simon
2016-11-22 13:30
mine run in less than a second

ghaskins
2016-11-22 13:31
if something takes 20 minutes, it should be in a later acceptance test but not uts

simon
2016-11-22 13:31
i don't think that anybody runs tests during development if they take 20 minutes

ghaskins
2016-11-22 13:31
but thats a sep issue...the primary issue right now is that the result of the run is not reliable

simon
2016-11-22 13:31
i don't buy it

ghaskins
2016-11-22 13:31
i agree. thats why UTs should be quick

ghaskins
2016-11-22 13:32
acceptance tests (like perhaps behave) can be in the pipeline to vet a commit/build for promotion

ghaskins
2016-11-22 13:32
but UTs should be quick to encourage dev workflow adoption

yacovm
2016-11-22 13:33
The problem with behave is that you can only test the system as a whole for that

yacovm
2016-11-22 13:33
you can't test a part of the system with behave

ghaskins
2016-11-22 13:33
im not advocating one over the other...just saying that something like behave and possible this 20 minute chaincode test are more "acceptance tests" than "unit-tests"

ghaskins
2016-11-22 13:34
at least in the definition that unit tests should be quick litmus test on the sanity of the code

ghaskins
2016-11-22 13:34
I realize the line can be blurry

ghaskins
2016-11-22 13:34
but I think the important takeaway is that we need the first phase of testing to be relatively quick checks to encourage devs to actually use them

jonathanlevi
2016-11-22 13:36
I really like Golang tests, btw, but you all probably know that.

jonathanlevi
2016-11-22 13:36
As for the Python BDD, what shall we do then?

jonathanlevi
2016-11-22 13:37
Shall we have a set of “smaller” Python tests (first) and then a full set of tests maybe?

jonathanlevi
2016-11-22 13:37
It is really frustrating, at development time to wait for 40 or even 20 mins.

simon
2016-11-22 13:37
these behave tests are dysfunctional

simon
2016-11-22 13:37
they are full of sleeps

jonathanlevi
2016-11-22 13:37
@simon: and I thought that I was being direct above :wink:

jonathanlevi
2016-11-22 13:38
They are full of sleeps, the parallelism is not consistent.

simon
2016-11-22 13:38
and they are totally inefficient due to lots of container creation and teardown

jonathanlevi
2016-11-22 13:38
And we have so much logic added as part of the tests, that’s outside the core functionality of fabric.

ghaskins
2016-11-22 13:39
from my perspective, the delineation should be between "quick things we want devs running _all_ the time" and "other tests that prove the mettle of a release that are run in the CI pipeline but not necessarily by hand"

jonathanlevi
2016-11-22 13:39
If you/one told me that we need an external set of “API testing” so we chose Python as a completely independent language or so… then I’d probably be much more OK with these. But at the moment, I don’t know if the overhead and pain is justifiable.

jonathanlevi
2016-11-22 13:40
@ghaskins Yes, I meant something along these exact lines. To separate to two (or so) test suites.

ghaskins
2016-11-22 13:40
and of course, we want both to be runnable by a dev if they need to check something

jonathanlevi
2016-11-22 13:40
Yup, locally, with a single CLI/command.

ghaskins
2016-11-22 13:40
it seems to me that we are _almost_ there today between "make unit-test" and "make behave", with the exception of the chaincode UTs

jonathanlevi
2016-11-22 13:40
Prior to submitting, and/or also for debugging, addressing issues.

ghaskins
2016-11-22 13:40
they are just too slow

jonathanlevi
2016-11-22 13:41
Yes, this is the main concern. We have the Makefile/targets, etc. The speed (and somewhat, reliability) seem to be the biggest issue.

ghaskins
2016-11-22 13:41
I dont have an opinion on the applicability of behave in this role

jonathanlevi
2016-11-22 13:42
@ghaskins: noted. We can still continue with Behave, should we be able to reduce testing time?

jonathanlevi
2016-11-22 13:42
And/or parallelize more?

jonathanlevi
2016-11-22 13:42
I agree with @garisingh, hardware should not be the issue.

jonathanlevi
2016-11-22 13:43
(or ‘an issue’)

jonathanlevi
2016-11-22 13:43
@simon: do you believe we can split the tests to two suites that make more sense? LIke a “quick pass” vs “full” ?

simon
2016-11-22 13:44
for unit tests?

jonathanlevi
2016-11-22 13:44
I am still worried as well about the time wasted indeed on the "teardown"

jonathanlevi
2016-11-22 13:44
(plumbing the Golang/Behave together)

jonathanlevi
2016-11-22 13:44
For the BDD tests

simon
2016-11-22 13:44
i don't see any benefit of the BDD as it is today

simon
2016-11-22 13:44
it's a weird english-like formalised language

jonathanlevi
2016-11-22 13:44
`BOOM` :slightly_smiling_face:

simon
2016-11-22 13:44
the tests take forever to run

simon
2016-11-22 13:45
they've been unreliable on my system from day 1

jonathanlevi
2016-11-22 13:45
BTW: I do know that most developers don’t really run them prior to submission.

simon
2016-11-22 13:45
yea of course not

simon
2016-11-22 13:45
it blocks your machine for one hour

ghaskins
2016-11-22 13:45
I dont have a problem with a framework that does full E2E testing, but I would like to see it run as efficiently as possible

ghaskins
2016-11-22 13:46
(and relegated to the "acceptance criteria" as opposed to a normal dev workflow

ghaskins
2016-11-22 13:46
so, to that point, if a bunch of tests are sleeping/waiting, they should be parallelized

simon
2016-11-22 13:46
change the code so that you can test it better

ghaskins
2016-11-22 13:48
anyway, behave is @jeffgarratts baby, we should include him

jonathanlevi
2016-11-22 13:48
True. Let’s wait a bit until more people wake up?

jonathanlevi
2016-11-22 13:48
@jeffgarratt

garisingh
2016-11-22 13:48
its 8:45 EST - people should be awake

garisingh
2016-11-22 13:48
:wink:

simon
2016-11-22 13:49
oh gari

simon
2016-11-22 13:49
not everybody gets up at 5am like you :slightly_smiling_face:

jonathanlevi
2016-11-22 13:51
@simon, in that note you sound like a true European :wink:

jonathanlevi
2016-11-22 13:51
[ I used to love it when the trains in London never worked early enough :wink: ]

simon
2016-11-22 13:51
i keep wondering how gari gets up so early

jonathanlevi
2016-11-22 13:53
It must be Fabric. It makes us all sleep extremely well at night. Don’t you feel it?

simon
2016-11-22 13:53
i do

simon
2016-11-22 13:53
well, i'm out of the project tomorrow

simon
2016-11-22 13:53
so no more good sleep

jonathanlevi
2016-11-22 13:53
Wait, what?

ghaskins
2016-11-22 13:53
@simon joke?

jonathanlevi
2016-11-22 13:53
@simon Really? PM'ing you now!

yacovm
2016-11-22 13:54
You don't know that?

simon
2016-11-22 13:54
lol

jonathanlevi
2016-11-22 13:54
<joking> Don’t tell us that it’s because you’d miss vagrant… !

jonathanlevi
2016-11-22 13:54
Is it really because of Docker?

jonathanlevi
2016-11-22 13:54
You never said anything!

jonathanlevi
2016-11-22 13:54
</joking>

simon
2016-11-22 13:54
no, i'm starting my own hardware/firmware design consulting company

ghaskins
2016-11-22 13:55
ah...sorry to hear: best of luck to you

simon
2016-11-22 13:55
thanks

jonathanlevi
2016-11-22 13:55
Yes, first of all, best of luck mate!

jonathanlevi
2016-11-22 13:55
Really sorry to hear/read about this!

jonathanlevi
2016-11-22 13:56
But it’s probably a good thing (for you!)

yacovm
2016-11-22 13:57
so, about the tests issue- is it possible to run the tests in CI in parallel? I mean, most unit tests don't need to connect to a peer, so why not have them run in a container of their own in parallel? Maybe it's possible to do something more smart than do `go list` and then run them in serial 1 by 1

jonathanlevi
2016-11-22 13:59
We had/have some tests that run the go side in parallel. We should look into what Behave can do for us. That is, whether it can spawn a few “jobs” that are independent.

jonathanlevi
2016-11-22 14:00
Yes, @yacovm, serializing them (with the delay/waits) is … Meh.

yacovm
2016-11-22 14:01
I wasn't talking about behave

yacovm
2016-11-22 14:01
I was talking about UTs

yacovm
2016-11-22 14:03
instead of doing an iteration over `go list`, maybe have at each time `K` containers running 1 package's tests. When a container finishes running a package, have it "grab" the next package and run it (or, to be precise- have the script that orchestrates this do that and launch a new container)

jonathanlevi
2016-11-22 14:05
@yacovm the UTs are relatively fast, but there are some examples for parallel (Golang) runs.

jonathanlevi
2016-11-22 14:05
I might be able to help with these, if you like.

yacovm
2016-11-22 14:10
They are *not* fast as a whole

bretharrison
2016-11-22 14:28
has joined #fabric-dev

ghaskins
2016-11-22 14:29
@yacovm I actually tried this a while back

ghaskins
2016-11-22 14:29
the results were not good

ghaskins
2016-11-22 14:30
they got slower, though this wasnt entirely a surprise

ghaskins
2016-11-22 14:31
that is: parallelism will only help workloads that trend towards io-bound...compute-bound jobs will degrade with parallelism...and I am not sure which category the UTs fall into

ghaskins
2016-11-22 14:31
id be happy to share my patch

ghaskins
2016-11-22 14:31
based on the result, it is implied they are compute bound

ghaskins
2016-11-22 14:32
(sorry, I should clarify my statement: compute-bound jobs will degrade if you increase concurrency without increasing parallelism )

ghaskins
2016-11-22 14:33
but since the number of available cores in things like vagrant and ci is both fixed and small, its tougher to exploit

ghaskins
2016-11-22 14:33
I have some really nice big iron in my lab where that is not the case :wink:

ghaskins
2016-11-22 14:33
but alas, not here

ghaskins
2016-11-22 14:34
to that point, and the point made earlier about LF/HL $$$, perhaps we throw bigger VMs at the problem

garisingh
2016-11-22 14:37
well if the CI team has time and we want to prove that compute power is part of the problem, I'm happy to provide access to some big iron if we can't immediately get something from LF.

garisingh
2016-11-22 14:37
:wink:

ghaskins
2016-11-22 14:38
ill see if I can find my patch

ghaskins
2016-11-22 14:40
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F35S6M4EQ/-.pl and commented: Probably needs to be ported, but should be trivial

ghaskins
2016-11-22 14:40
@garisingh ^^^

yacovm
2016-11-22 14:41
don't the chaincode UTs run in 20 min?

ghaskins
2016-11-22 14:41
well, locally they run 400-500s

ghaskins
2016-11-22 14:41
just lately, on CI, they take 1100s typically

yacovm
2016-11-22 14:42
ok, so if you run them in parallel, you save 500s if the other tests combined are more than 500s

ghaskins
2016-11-22 14:42
that has nothing to do with this

ghaskins
2016-11-22 14:42
I wrote that patch back in June for one thing, when we were looking at 60m travis runs

ghaskins
2016-11-22 14:42
personally, I think that chaincode test needs to be reworked

ghaskins
2016-11-22 14:43
so, consider the "parallel" discussion as orthogonal to the chaincode UT discussion

ghaskins
2016-11-22 14:43
but yes, if you did it at package level, we would be gated by largest package

ghaskins
2016-11-22 14:43
that wasnt what I was referring to though

ghaskins
2016-11-22 14:44
what I was referring to was that overall the times went up

ghaskins
2016-11-22 14:45
on a tangent: what I am currently thinking is we change "make unit-test" and "make behave" to "make quick-test" and "make acceptance-test" or something like that

ghaskins
2016-11-22 14:45
and then move chaincode UT and behave under acceptance test

yacovm
2016-11-22 14:50
well that was only a thought

ghaskins
2016-11-22 14:51
understood, and it was a good one

ghaskins
2016-11-22 14:52
just reporting that was not a factor in the assessment

jeffgarratt
2016-11-22 15:28
@jonathanlevi @garisingh @ghaskins sorry I missed the discussion wrt to BDD. What is the crux of the issue?

simon
2016-11-22 15:28
it's slow

jeffgarratt
2016-11-22 15:28
ahhh, the latest version support parallelization

jeffgarratt
2016-11-22 15:29
at the feature level

jeffgarratt
2016-11-22 15:29
so if we can separate the tests features logically, we should be able to reap some speed up benefits

jonathanlevi
2016-11-22 15:30
That’s what I was hoping (above) @jeffgarratt

jeffgarratt
2016-11-22 15:30
both the go and behave BDDs can run in parallel, though you lose the BDD output on the godog side

jeffgarratt
2016-11-22 15:31
correct, we could spawn the various feature files independently and concatenate the results

jeffgarratt
2016-11-22 15:32
I am working on the boostrap.feature at the moment as it is the basis for all future compositions within any feature we build hereafter

jeffgarratt
2016-11-22 15:32
ie,, the old "given we compose" must effectively bootstrap the network properly per run

jeffgarratt
2016-11-22 15:33
was slow the only issue?

jonathanlevi
2016-11-22 15:39
I think slowness and the fact that some of them are/were flaky.

jonathanlevi
2016-11-22 15:39
(not necessarily due to Behave)

jonathanlevi
2016-11-22 15:41
The context (above) was mostly around what should be the “merging policy”. Do we require that everything is built and “signed/approved” by the CI prior to a merge, shall we continue to have cases where we allow maintainers to just “verify” manually a changeset and merge it, etc.

jeffgarratt
2016-11-22 15:41
as of this point the only active features are in the bddtests/features folder

jonathanlevi
2016-11-22 15:41
Then we talked about cases where the CI is down, or when we don’t have the time to “wait” for the tests...

jonathanlevi
2016-11-22 15:42
[That’s my vague “Executive Summary” of the above ;-)]

jeffgarratt
2016-11-22 15:42
good deal

jeffgarratt
2016-11-22 15:42
thnx

jonathanlevi
2016-11-22 15:42
A more general question is whether we should port these at some point ?

jonathanlevi
2016-11-22 15:43
I personally, am asking people to write more UT in Golang.

jeffgarratt
2016-11-22 15:43
I have a movie that shows the mechanism for creating BDDs then porting to golang

jeffgarratt
2016-11-22 15:43
perhaps I forgot to post it

jonathanlevi
2016-11-22 15:43
Especially while we are refactoring so much.

jonathanlevi
2016-11-22 15:43
@jeffgarratt Or maybe you did, and I have missed it. Would love to see it.

jeffgarratt
2016-11-22 15:43
I write in behave first as it is generally much more terse and readable

jeffgarratt
2016-11-22 15:44
let me go check, was working on write before vacation... perhaps I jumped before hitting the button :slightly_smiling_face:

jonathanlevi
2016-11-22 15:44
The description/test is top notch. I used to work with Cucumber, etc.

jonathanlevi
2016-11-22 15:45
Is it possible to use a similar description language with Golang binidngs? Like the Ginkgo, etc.? I remember a discussion about that back in v0.5, but I personally haven’t done much in that regard, I have to admit.

jeffgarratt
2016-11-22 15:46
the current bddtests support python and golang with the same Gherkin feature file

jeffgarratt
2016-11-22 15:46
there are examples of both

jeffgarratt
2016-11-22 15:46
using the same feature file :slightly_smiling_face:

jeffgarratt
2016-11-22 15:46
works like a charm

jeffgarratt
2016-11-22 15:46
and we reuse all of the feature files we write

jonathanlevi
2016-11-22 15:46
That’s awesome! (I didn’t know that)

jeffgarratt
2016-11-22 15:47
yeah, It is pretty nice

jeffgarratt
2016-11-22 15:47
will dig the movie up, post to box and push out the link

oiakovlev
2016-11-22 16:48
Hi question if I want to run few peers on different physical machines which options do I have for the peers to discover each other?

oiakovlev
2016-11-22 16:49
so more correct question: will docker-compose on each host work and what are the tricks there, so peers will discover membersvc and other peers?

oiakovlev
2016-11-22 16:53
will `CORE_VM_ENDPOINT` work for this and what will be correct address for this? or `CORE_PEER_DISCOVERY_ROOTNODE` might help - the question is the similar, what are correct/working example...?

oiakovlev
2016-11-22 16:53
I'm asking in context of v06...

ghaskins
2016-11-22 16:54
@oiakovlev its the CORE_PEER_DISCOVERY_ROOTNODE you want to be looking at

ghaskins
2016-11-22 16:55
the VM_ENDPOINT is related to how the peer communicates with dockerd

oiakovlev
2016-11-22 16:55
ok how to link two different `docker-compose.yml`s?

ghaskins
2016-11-22 16:55
"discovery" is a little weak in v0.6 and older: its more of an apriori whitelist than true discovery

oiakovlev
2016-11-22 16:56
right now I use `CORE_PEER_DISCOVERY_ROOTNODE=vp0:7051` which works because vp0 is in the same docker compose, if these are differnet host and different files, what will do the trick?

ghaskins
2016-11-22 16:56
im not sure, but I think you would either want to use a downstream composition of the two, or use docker links

ghaskins
2016-11-22 16:56
if you want to use compose AND use different hosts, look at docker-swarm

ghaskins
2016-11-22 16:56
thats what that is meant for

yacovm
2016-11-22 16:56
You can make the CORE_PEER_DISCOVERY_ROOTNODE a list too, btw

yacovm
2016-11-22 16:57
unless that PR of mine has been un-merged since

ghaskins
2016-11-22 16:57
i havent tried this personally, but my understanding is docker-swarm is a superset of compose, designed for multi-host

oiakovlev
2016-11-22 16:57

ghaskins
2016-11-22 16:57
fwiw, I use kubernetes/openshift as an alternative to swarm, but same concepts

ghaskins
2016-11-22 16:59
@oiakovlev that is somewhat old (looks like docker v1.9/2015

ghaskins
2016-11-22 17:00
theres been a bunch of stuff done since then: i would start here: https://docs.docker.com/swarm/overview/

oiakovlev
2016-11-22 17:00
@pmcosta ^^ this is what we discussing

pmcosta
2016-11-22 17:00
has joined #fabric-dev

ghaskins
2016-11-22 17:01
the main rub is: if you want to use docker-links (e.g. "vp0") it has to be within an SDN that docker controls AFAICT

ghaskins
2016-11-22 17:01
swarm would buy you that

ghaskins
2016-11-22 17:01
otherwise, you would need to manage the ip namespace some other way

ghaskins
2016-11-22 17:01
(which is doable, btw)

oiakovlev
2016-11-22 17:01
ok, so swarm bring me some sort of composition of different docker-compose.yml? I can think of it like this

oiakovlev
2016-11-22 17:02
and that's how my peers will know what vp0 means, right?

ghaskins
2016-11-22 17:02
im not sure as I have never used it, but I dont think that is quite right

ghaskins
2016-11-22 17:02
rather, I think what swarm does is add multi-host orchastration to your composition

ghaskins
2016-11-22 17:03
keep in mind, I am no swarm expert..but I do use other orchestration layers and I have a sense of what swarm is likely doing

ghaskins
2016-11-22 17:03
in that sense, I suspect it still wants to work within one composition/link namespace, but can distribute the jobs across the cluster rather than within a single node

yacovm
2016-11-22 17:04
keep in mind, if you use pbft you have to make the peer's IDs be vp0, vp1 etc etc

oiakovlev
2016-11-22 17:04
ok another more generic question: what other options do we have to run real network on few physical nodes?

oiakovlev
2016-11-22 17:04
and yes we have pbft enabled :slightly_smiling_face:

yacovm
2016-11-22 17:04
where is the problem exactly?

ghaskins
2016-11-22 17:04
if you wanted to join two compositions, you are probably better off defining a new composition that includes the other two

ghaskins
2016-11-22 17:04
I am not sure there is any other way to do it

ghaskins
2016-11-22 17:04
that way "vp0" etc have meaning in context

oiakovlev
2016-11-22 17:05
the statement of problem - is how to run few peers on different machines correctly so they discover each other

oiakovlev
2016-11-22 17:05
with pbft, security and privacy enabled :slightly_smiling_face:

oiakovlev
2016-11-22 17:05
maybe I asked initially incorrectly starting with `docker-compose`

ghaskins
2016-11-22 17:05
if all you want to do is run them, you can just use IP/DNS instead of docker links

ghaskins
2016-11-22 17:05
you just have to manage it yourself

yacovm
2016-11-22 17:06
Just put in the `CORE_PEER_DISCOVERY_ROOTNODE` a list of some of the addresses of them or something

ghaskins
2016-11-22 17:06
all docker-compose is doing is providing a DNS context

yacovm
2016-11-22 17:06
and try it out

yacovm
2016-11-22 17:06
oh

ghaskins
2016-11-22 17:06
so if you define a node "vp0", it will surface as a dns name that other hosts within that definition can lookup

yacovm
2016-11-22 17:06
you're asking how to configure everything?

ghaskins
2016-11-22 17:07
theres no real magic, its just convenient to define relative relationships

oiakovlev
2016-11-22 17:07
nope, nope everything is running with single docker-compose

oiakovlev
2016-11-22 17:07
on the single node

oiakovlev
2016-11-22 17:07
just wnated to double check if direct ip will work

ghaskins
2016-11-22 17:07
right, so you are still using SDN, its just not a very topologically complicated environment :wink:

oiakovlev
2016-11-22 17:08
and if `CORE_PEER_DISCOVERY_ROOTNODE` is the correct param for it

ghaskins
2016-11-22 17:08
but you dont have to use SDN

ghaskins
2016-11-22 17:08
yes, it is

oiakovlev
2016-11-22 17:08
ok, thanks!

ghaskins
2016-11-22 17:08
subst "vp0" for the ip/dns name of where the "rootnode" really is, and it will work

oiakovlev
2016-11-22 17:08
cool, this is not prod, this is some sort of PoC

oiakovlev
2016-11-22 17:08
Thanks a lot!

ghaskins
2016-11-22 17:08
perfect

ghaskins
2016-11-22 17:08
np

yacovm
2016-11-22 17:09
@donovanhide maybe you have a config file or something? I recall you ran fabric with docker swarm?

yacovm
2016-11-22 17:10
oh wait, you're not using swarm? you're just using different physical machines? @oiakovlev

donovanhide
2016-11-22 17:10
I was using kubernetes..

oiakovlev
2016-11-22 17:10
right now just differnet physical machines, but I guess this works for some initial testing but swarm will be next step

oiakovlev
2016-11-22 17:11
as managing manually few different docker-composes for each host is not something we like :slightly_smiling_face:

yacovm
2016-11-22 17:11
oh, right. I always mix them up. Sorry ^^

oiakovlev
2016-11-22 17:11
so if there is any example for correct setup exist - it will be really helpful

oiakovlev
2016-11-22 17:11
hm... for correct = for more advanced setup :slightly_smiling_face:


yacovm
2016-11-22 17:14
try this one

yacovm
2016-11-22 17:14
not sure if it's up to date regarding port numbers and stuff

yacovm
2016-11-22 17:14
but I guess you can "start" with this


yacovm
2016-11-22 17:14
This is one with SSL, etc.

oiakovlev
2016-11-22 17:17
thanks @yacovm we have all this and it works on single machine - to run it on different physical machines we'll need to split it in few files and push to each host it's own config. My question was - if we can avoid it, have some sort of common config instead. Will swarm help here? Or I miss the point?

yacovm
2016-11-22 17:18
Maybe. I don't know, never used swarm

oiakovlev
2016-11-22 17:18
so this is just the question of conf management - having host specific config might be tricky... even if they are really similar and the difference is just between mbrsvc, vp0 and rest hosts. And rest vp1..N docker-compose will be really similar - the difference is just in vpN...

ghaskins
2016-11-22 17:21
@oiakovlev my impression is, with swarm the cluster is transparent

ghaskins
2016-11-22 17:22
its like doing "docker-compose up" but its cluster aware so the location of the jobs is distributed

ghaskins
2016-11-22 17:22
so, theres no need to split the composition up

ghaskins
2016-11-22 17:22
swarm will split it for you as part of its orchestration function

oiakovlev
2016-11-22 17:22
sounds cool but there is no example? nobody tried it?

ghaskins
2016-11-22 17:22
im sure others have, i use kubernetes myself

ghaskins
2016-11-22 17:23
(which is overlapping in concept with swarm)

oiakovlev
2016-11-22 17:23
also question - how the deployment inside bluemix is done - is it always now single virtual host with single docker-compose?

oiakovlev
2016-11-22 17:23
maybe, you are aware :slightly_smiling_face:

ghaskins
2016-11-22 17:23
@garisingh is your man on bluemix questions

ghaskins
2016-11-22 17:24
i havent tried that platform yet

oiakovlev
2016-11-22 17:24
when I tried it, it was black box from outer world...

ghaskins
2016-11-22 17:25
sorry, i have to defer to Gari

ghaskins
2016-11-22 17:25
@oiakovlev you know more about it than I do at this point :wink:

oiakovlev
2016-11-22 17:26
Thanks a lot !

ghaskins
2016-11-22 17:26
anytime

garisingh
2016-11-22 18:00
@oiakovlev - the Bluemix Blockchain Starter Plan is a shared compute environment. We deploy everything as Docker containers - we have hosts dedicated for each type of peer - vp0,vp1,vp2,vp3 with membersrvcs spread across those hosts (this way we can lose one host but still have 2f+1 (3) peer per network. We then have multiple Docker hosts for running chaincode - basically we have separate hosts for chaincode from each peer type as well. We run all of this over a Docker overlay network

oiakovlev
2016-11-22 18:00
and how docker cluster is managed?

oiakovlev
2016-11-22 18:01
swarm any other tool? or just separate docker-compose for each host?

garisingh
2016-11-22 19:34
we use Swarm for overall mgmt but we deploy somethings directly to the Docker hosts via the Docker remote API (we actually have a NodeJS app / process we use to do this)

garisingh
2016-11-22 19:35
we also use nghttp2 as a reverse proxy to do host header-based routing so that we don't directly expose the endpoints to the Internet

garisingh
2016-11-22 19:35
and we use Consul as the KV store for both Swarm and for the overlay network

oiakovlev
2016-11-22 22:27
thanks

squeue
2016-11-23 05:46
has joined #fabric-dev

jkilpatr
2016-11-23 14:40
so if I have my own custom fabric base-image and I run peer-docker it looks like the binary is built elsewhere before being pushed into the peer image (I edited its docker file) what sort of pipeline does it follow?

jkilpatr
2016-11-23 15:04
@ghaskins ^

ghaskins
2016-11-23 15:10
@jkilpatr: not clear on what you are trying to do. Can you elaborate?

ghaskins
2016-11-23 15:11
I assume you mean to ask where the build/docker/bin/peer binary comes from before I stuff it?

ghaskins
2016-11-23 15:12
If so, it's all in the top level Makefile

ghaskins
2016-11-23 15:12
Be happy to walk through it

jkilpatr
2016-11-23 15:46
@ghaskins hence my confusion build peer doesn't work (RHEL native) but build peer-docker does, at first I thought it was because it was all containerized and my centos container works fine, but then I see that build peer-docker calls build peer which doesn't work when I call it and got very confused.

ghaskins
2016-11-23 15:47
I am reasonably confident that peer-docker does not call peer

ghaskins
2016-11-23 15:48
what makes you think that it does?

jkilpatr
2016-11-23 15:50
nevermind I suffer from stupid or maybe just too many tests running

jkilpatr
2016-11-23 15:50
peer: build/bin/peer peer-docker: build/image/peer/.dummy

jkilpatr
2016-11-23 15:50
so its the dummy not the peer build.

ghaskins
2016-11-23 16:01
right, and really that is just an alias

ghaskins
2016-11-23 16:01
peer-docker == build/image/peer/.dummy

jkilpatr
2016-11-23 16:01
I'm kinda seeing it now, the ccenv and the javaenv right?

ghaskins
2016-11-23 16:02
yeah...the issue is two fold

ghaskins
2016-11-23 16:02
1) make only knows how to evaluate files, whereas docker images are not files

jkilpatr
2016-11-23 16:02
yeha this make -> docker stuff is really odd to me. I'm not exactly a make wiz normally either.

ghaskins
2016-11-23 16:02
2) phony-targets like "peer-docker" are bad to use in general since they always evaluate as needing to be rebuilt

ghaskins
2016-11-23 16:03
so, if I said "foo: bar" where bar is a phony target, "foo" will _always_ need to be rebuilt

ghaskins
2016-11-23 16:03
so its better to quickly translate into files asap

ghaskins
2016-11-23 16:03
and then use those, so make can (more correctly) eval the system state

ghaskins
2016-11-23 16:04
e.g. bar: build/bar/.dummy\nfoo: build/bar/.dummy

ghaskins
2016-11-23 16:04
would yield superior performance, if but a bit ugly

jkilpatr
2016-11-23 16:04
ok so the dummy files are used to signal to make, the one I looked at was blank, should it contain a hash or somthing?

jkilpatr
2016-11-23 16:05
oh wait timestamp on the file

ghaskins
2016-11-23 16:05
yeah, its based on timestamps

ghaskins
2016-11-23 16:05
but to that point, I do need to enhance them with the gitsha

ghaskins
2016-11-23 16:05
e.g. build/images/peer/.dummy-$sha

ghaskins
2016-11-23 16:06
because we have a problem right now where someone can change their git tree but make doesnt detect it needs to rebuild

ghaskins
2016-11-23 16:07
this materializes in .dummy being satisifed, but dependendies between docker containers are not

ghaskins
2016-11-23 16:07
i digress

ghaskins
2016-11-23 16:07
neither here nor there

ghaskins
2016-11-23 16:07
none of this would be a problem if docker-images surfaced as part of the posix filesystem

ghaskins
2016-11-23 16:07
but they dont, so I had to get clever

jkilpatr
2016-11-23 16:07
so right now I'm just trying to figure out next steps, that would be the javaenv and the ccenv, I guess I can leave the javaenv alone and not port it to redhat land

jkilpatr
2016-11-23 16:08
this is going to be so much easier if we convince RH management to just package all this crap for us in a special repo.

ghaskins
2016-11-23 16:08
let me ask you this: aside from branding optics, what does it matter whats inside the container

ghaskins
2016-11-23 16:08
is there a technical reason too?

jkilpatr
2016-11-23 16:09
there are lots of people using rhel that face significant certification requirments for all software they run

ghaskins
2016-11-23 16:09
you could convievably just run docker containers on RHEL/CentOs without caring the contents

jkilpatr
2016-11-23 16:09
so... rhel, rhel everywhere.

ghaskins
2016-11-23 16:09
ah, I see

ghaskins
2016-11-23 16:09
yes, this makes sense

jkilpatr
2016-11-23 16:09
these are many of the same customers interested in blockchain/hyperledger

jkilpatr
2016-11-23 16:09
¯\_(ツ)_/¯

ghaskins
2016-11-23 16:10
well, I would very much like to stay in the loop with what you are doing in making multi $distro something we can support upstream if its reasonable to do so

jkilpatr
2016-11-23 16:10
ghaskins base image/ peer took me all of 15 min once I figured out what I was doing really

ghaskins
2016-11-23 16:10
im not quite sure what that might end up looking like, but lets work together

jkilpatr
2016-11-23 16:10
agreed

ghaskins
2016-11-23 16:11
we still have ubuntu-isms sprayed everywhere, but we can work on cleaning those up

jkilpatr
2016-11-23 16:11
the big problem is handling all the funky dependencies, over in rhel land we have to package them and sign off anyways so we can skip that problem downstream

jkilpatr
2016-11-23 16:11
but upstream I think we should move to put all the dependency handling into system agnostic scripts and then have components for the distro specific stuff

ghaskins
2016-11-23 16:11
yeah...i have long thought that using a higher-level provisioner (like puppet) might be easier to normalize the dependency specification than our current bash approach

ghaskins
2016-11-23 16:11
thoughts?

jkilpatr
2016-11-23 16:12
we're an ansible shop, but i can learn puppet, anything is better than bash in large quantities

ghaskins
2016-11-23 16:12
to be clear, I just mean the stand-alone puppet thing that can process a manifest file, not a full scale client/server setup

ghaskins
2016-11-23 16:12
im not against ansible...i just dont know it

ghaskins
2016-11-23 16:12
ive worked with puppet, so that was my go-to

jkilpatr
2016-11-23 16:13
to be honest puppet is probably better for this ansible can do cool things locally but its smarts are tied up doing remote admin

ghaskins
2016-11-23 16:13
I think conceptually, any devop-like thing (puppet/chef/ansible) would get us closer to $distro neutral

jkilpatr
2016-11-23 16:13
+1

ghaskins
2016-11-23 16:13
I have nothing against bash, and in fact favor it when I know $distro is not a factor

ghaskins
2016-11-23 16:13
its just simple and reliable

jkilpatr
2016-11-23 16:14
I often still don't understand bash parsing rules. The issue is how messy it gets when you need to do more complicated stuff

jkilpatr
2016-11-23 16:14
but copy / install / build sure

ghaskins
2016-11-23 16:14
thats probably true

ghaskins
2016-11-23 16:15
anyway, long story short, id be interested in seeing if a $distro neutral approach could be adopted upstream, so lets hammer it out together so you dont end up with a one-off you have to maintain on the side

jkilpatr
2016-11-23 16:17
agreed, setup a meeting sometime after the holiday then? Or maybe just start passing around a gdoc?

ghaskins
2016-11-23 16:17
either way

ghaskins
2016-11-23 16:17
though after the holiday either way

ghaskins
2016-11-23 16:17
im about T-45m away from kicking out for the week

ghaskins
2016-11-23 16:18
:wink:

ghaskins
2016-11-23 16:18
though knowing me, ill still be slack-lurking even through turkey dinner

jkilpatr
2016-11-23 16:20
have a good thanksgiving!

klorenz
2016-11-23 16:20
has joined #fabric-dev

muralisr
2016-11-23 16:21
@ghaskins ` T-45m away from kicking out for the week` … I was going to say …hmmm :slightly_smiling_face:

muralisr
2016-11-23 16:21
(Happy Thanksgiving!)

ghaskins
2016-11-23 16:22
ty sir, likewise

ghaskins
2016-11-23 16:24
@jkilpatr you too

alanlee
2016-11-23 16:58
has joined #fabric-dev

ratnakar
2016-11-23 17:04
After cleanup I ended up with the below error , Unable to create the docker images `"make: *** No rule to make target build/bin/orderer" needed by 'orderer'. Stop." `

ratnakar
2016-11-23 17:05
can some one help me how to get rid of this issue

ramesh
2016-11-23 17:08
@ratnakar I am able to build images on latest commit using `make docker`

ratnakar
2016-11-23 17:13
@ramesh I was able to generate too .. However after `make clean` it is not working any more and ended up with this error. not really sure what is going wrong here

ghaskins
2016-11-23 17:19
hey guys, OTP but ill ping you back shortly

jonathanlevi
2016-11-23 19:39
@jonathanlevi uploaded a file: https://hyperledgerproject.slack.com/files/jonathanlevi/F35P1JPCY/_build_nextroundofdockercrs.png and commented: BTW: I have just merged 3 of Greg’s CRs to `master`, and for working with the latest, you might need to `vagrant destroy`, etc. Greg will send an email shortly with instructions.

jonathanlevi
2016-11-23 19:41
[ Thank you @ghaskins for working to get rid of vagrant, in the spirit of Thanksgiving, etc. Updated :wink: ]

ghaskins
2016-11-23 19:56
well, we arent quite there yet, but soon

ghaskins
2016-11-23 19:56
for one, I havent addressed behave

ghaskins
2016-11-23 19:57
also, the "peer chaincode" CLI still needs native binaries, and the documentation needs to be updated

ghaskins
2016-11-23 19:57
I will be working with @nickgaski on the doc after the holiday

ghaskins
2016-11-23 19:57
so, for the time being, certain use cases will still rely on vagrant (namely, CLI users)

ghaskins
2016-11-23 19:58
(and behave

ghaskins
2016-11-23 19:58
the biggest challenge is that we need docker v1.8.1 but the current vagrant baseimage ships v1.5.2

ghaskins
2016-11-23 19:58
thus the need for the destroy

ghaskins
2016-11-23 19:58
sorry, compose v1.8.1

jonathanlevi
2016-11-23 20:01
I have approved that too I think. Need another.

jjmiranda
2016-11-23 23:20
has joined #fabric-dev

ankitkamra
2016-11-24 02:47
has joined #fabric-dev

jonathan.tan
2016-11-25 07:06
has joined #fabric-dev

jonathan.tan
2016-11-25 07:08
Hi All, just a quick question regarding the Table API and the GetRows command, does anyone know would there be a new feature in future versions (we’re on 0.6 now) where the GetRows command could do some form of pagination / limits? There could be a usecase where 10,000 “Rows” would be returned and I could imagine , that call would take an impact on the peer.

ankitkamra
2016-11-25 09:27
hi i am facing following issue while deploying chaincode :- vp0_1 | 09:16:17.441 [dockercontroller] deployImage -> ERRO 025 Error building images: Post http://172.17.0.1:2375/build?t=dev-vp0-0f5b1d65041bc6d500bd0f1cab50eb6154c291ef0f4596d64b6797e8ef8f7c34a179b5a2cea82253ff3d74e768512fe0481503eadcf13d18f9761bbb8133efd0: dial tcp 172.17.0.1:2375: getsockopt: no route to host vp0_1 | 09:16:17.441 [dockercontroller] deployImage -> ERRO 026 Image Output: vp0_1 | ******************** vp0_1 | vp0_1 | ******************** vp0_1 | 09:16:21.453 [dockercontroller] Start -> ERRO 027 start-could not recreate container Post http://172.17.0.1:2375/containers/create?name=dev-vp0-0f5b1d65041bc6d500bd0f1cab50eb6154c291ef0f4596d64b6797e8ef8f7c34a179b5a2cea82253ff3d74e768512fe0481503eadcf13d18f9761bbb8133efd0: dial tcp 172.17.0.1:2375: getsockopt: no route to host vp0_1 | 09:16:21.453 [chaincode] Launch -> ERRO 028 launchAndWaitForRegister failed Error starting container: Post http://172.17.0.1:2375/containers/create?name=dev-vp0-0f5b1d65041bc6d500bd0f1cab50eb6154c291ef0f4596d64b6797e8ef8f7c34a179b5a2cea82253ff3d74e768512fe0481503eadcf13d18f9761bbb8133efd0: dial tcp 172.17.0.1:2375: getsockopt: no route to host

ankitkamra
2016-11-25 09:27
any help

ankitkamra
2016-11-25 09:27
?

oiakovlev
2016-11-25 10:44
Hi All. When we deploy chaincode it prepares some deployment package and on deployment it creates docker image inside peer, right? So the question: what is included in deployment package? and what is requirement for the instance which makes a deployment? I mean if I deploy using NodeSDK to remote peer - what dependencies should be installed on this host: my chaincode, go dependencies, peer images - and why?

garisingh
2016-11-25 14:00
@oiakovlev - when you deploy chaincode from the NodeSDK (or in the future any of the client SDKs), the "deployment package" is basically a tarball which contains the information for being able to create an image using the Docker Remote API (so basically a Dockerfile and any contents which are needed to run "build image"). The default Dockerfile created by the SDKs (currently) requires that you include the source for your chaincode as well as any external dependencies (which also includes the fabric src) packaged in the vendor folder of your chaincode directory in order to deploy

oiakovlev
2016-11-25 14:19
@garisingh thanks. It make sense - but what we phased yesterday (based on v06) deploying from remote NodeSDK to the peer is that it caused chaincode start error on peer before we have not pulled docker images on NodeSDK, which was a bit odd.. is it expected to pull docker images on NodeSDK to deploy chaincode or did we mixed something?

oiakovlev
2016-11-25 14:43
And another related question - can we add node dynamically while running with PBFT enabled? So the question is we are running on few different physical instances (so running instance one by one with different docker-compose) and it works but we have not enabled PBFT yet. Crossing fingers and will try now - but should we expect any issues or not really?

oiakovlev
2016-11-25 15:11
Sorry, for the 1st question docker images not needed on NodeSDK - rechecked - my mistake, so go dependencies were missed...

garisingh
2016-11-25 18:11
@oiakovlev - in v0.6 with PBFT you cannot dynamically add a validating peer / node

alanlee
2016-11-26 02:41
Hi @garisingh , will v1.0 allow "PBFT while allowing dynamically add validating peer"? This is quite important features in live expansion of nodes. Thank you.

tuand
2016-11-26 03:14
@alanlee v1.0 drastically reorganizes the various fabric components. Suggest you got to https://wiki.hyperledger.org/community/fabric-design-docs )

alanlee
2016-11-26 03:30
Thanks @tuand

kostas
2016-11-26 04:27
@alanlee: This is in our radar, but there is no timeline for when this will be ready, and no code to show for the dynamic addition of BFT ordering nodes at this time either.

alanlee
2016-11-26 07:58
Thanks @kos'

vdods
2016-11-26 22:28
Hi all, are there any docs on the various data types used in ChaincodeStubInterface for user/transaction authentication -- like GetCallerCertificate, GetCallerMetadata, GetBinding, GetPayload -- these terms don't seem to be well-defined in any document I've found so far.

hsukhwa
2016-11-28 00:41
has joined #fabric-dev

jonathan.tan
2016-11-28 02:39
@vdods I am looking for such documentation as well.

ry
2016-11-28 02:43
@jonathanlevi @garisingh the CI hardware is sized to be ~equal to @cbf's Macbook Pro.

tbltzk
2016-11-28 15:35
has joined #fabric-dev

jefftenn
2016-11-28 19:28
has joined #fabric-dev

jefftenn
2016-11-28 19:29
Hi, I am attempting to run go build ./* from the IBM-Blockchain/learn-chaincode/start folder, on my Mac. I already have run a simple hello-world go build on the system without any issues, but when I ran the go build./*, the build hung. After ctrl-c out of the build command, any build attempts now fail with a fatal error unexpected signal during runtime execution. runtime.sigpanic(). I was wondering if anyone else had experienced anything similar. Thanks!

jefftenn
2016-11-28 19:39
Looks like there are issues with Go and Mac Sierra (according to the golang/go git issues.

ghaskins
2016-11-28 20:05
@garisingh do you know the timeline for the goleveldb change?

ghaskins
2016-11-28 20:05
I have my --static patches in the last phases of test....so if its more than 1-week out, I still would suggest a new baseimage with updated .a

ghaskins
2016-11-28 20:06
it shouldnt really impact anything other than my effort to produce a new release, which I am willing to do

garisingh
2016-11-28 20:16
The code does not use rocks anymore as far as I can tell. I asked on the ledger channel when they plan to delete the rocks code

dave.enyeart
2016-11-28 20:26
goleveldb is the default database already. RocksDB is not used in any code, and will be completely removed from the code and environments in the next week or so.

garisingh
2016-11-28 20:49
@ghaskins: if you want me to +2 your CR I can

karl.e
2016-11-28 21:19
has joined #fabric-dev

karl.e
2016-11-28 21:23
Hi all, SK here; we're currently on sprint 4 (182a8672aaceacdbc3a9673d420a2c0bbcb5300c fabric and 4d706854822211c63694a72dccd9ad9353f29cee fabric-node-sdk). Is there a similar end-of-sprint5 state we could upgrade to? Thanks.

ruslan.ardashev
2016-11-29 14:04
has joined #fabric-dev

ruslan.ardashev
2016-11-29 14:44
(hopefully this is the right place to ask) with v1 coming out soon & its new consensus, don't we remove a lot of the security inherent to blockchain by limiting the transaction to relevant parties?

ruslan.ardashev
2016-11-29 14:46
(by security I mean the data replication and lack of a need for reconciliation that’s inherent to blockchain)

ruslan.ardashev
2016-11-29 14:48
would also like to ask about transaction confidentiality - I've been under the impression that even though each validating peer can see the data, we hide details away by running the transactions in a secure process (that runs the chaincode). is this a correct way of looking at things? here (https://hyperledger-fabric.readthedocs.io/en/latest/abstract_v1/) it says that up until now " Every peer can see the logic for every transaction."

garisingh
2016-11-29 14:49
@ruslan.ardashev - I am honestly not sure why people actually think that blockchains are more secure than other types of data stores, but I do see these types of questions / comments quite often.

garisingh
2016-11-29 14:50
if you run a public, permissionless blockchain, then clearly the greater the number of validating / storage nodes, the harder it will be for someone to take over the chain and or modify (or even just wholesale wipeout) the data

ruslan.ardashev
2016-11-29 14:51
yeah maybe secure was a bad term. to expand a bit I mean in terms of hacking - when you replicate your data store across more parties you have less risk (more secure) if one node gets hacked

ruslan.ardashev
2016-11-29 14:51
exactly

ruslan.ardashev
2016-11-29 14:52
so don’t we significantly lose out on this by limiting transactions to relevant parties?

ruslan.ardashev
2016-11-29 14:53
how does everyone have a consistent view of the dB if not everyone gets a copy of the transaction?

ruslan.ardashev
2016-11-29 14:53
and weren’t we previously running all transactions on all nodes without visibility to all users via secured processes?

ruslan.ardashev
2016-11-29 14:53
so many questions lol

anton
2016-11-29 15:12
has joined #fabric-dev

vikasjakhar
2016-11-29 17:40
has joined #fabric-dev

ghaskins
2016-11-29 18:15
@yacovm now seeing this one: FAIL http://github.com/hyperledger/fabric/gossip/gossip 157.839s in a local run

yacovm
2016-11-29 20:47
@ghaskins pics or didn't happen :wink:

ghaskins
2016-11-29 20:52
understood, and sorry, will grab next time.

ghaskins
2016-11-29 20:52
I mostly was reporting that I now saw it local (previously there were comments about it only occuring in CI)

yacovm
2016-11-29 20:52
np, just didn't want this to hang in the air because it looks to a 3rd party that I'm ignoring you

ghaskins
2016-11-29 20:52
right, sorry

ghaskins
2016-11-29 20:52
@yacovm response time = superb :wink:

arnaud
2016-11-29 21:08
@ruslan.ardashev @garisingh from what I understand permissioned blockchains have over other datastores the advantage of being temper-evident, while permissionless blockchains have the advantage of being temper-proof (albeit after a certain number of blocks have been validated)

arnaud
2016-11-29 21:09
but I too would like a more refined answer because I get a lot of questions from people as to what the real advantage is over distributed databases

ruslan.ardashev
2016-11-29 21:09
even if we ignore the concept of permissioned versus permissionless for a second, it seems that v1 will isolate transactions to only relevant parties (only a few nodes) versus distributing them across the entire system

ruslan.ardashev
2016-11-29 21:10
seems to eliminate one of the key benefits of blockchain imo

arnaud
2016-11-29 21:10
yes

ruslan.ardashev
2016-11-29 21:10
(the fact that data is replicated and eliminates the need for reconciliation)

ruslan.ardashev
2016-11-29 21:12
one of the reasons cited for doing this was “additional security” because we only expose the data to relevant parties in doing so. but I was under the impression that we always distributed each transaction network-wide and never exposed data thanks to secure processes

ruslan.ardashev
2016-11-29 21:12
(that run the chaincode, are given the decryption keys to everything during setup, and then securely run as to not expose the keys or data)

arnaud
2016-11-29 21:23
well, the "additional security" from what I understand refers to not putting on the ledger accessible by parties/peers data you don't want to share with them

arnaud
2016-11-29 21:25
it does enable use cases that are hard to handle otherwise

arnaud
2016-11-29 21:25
but like permissioned networks which are seen as heretic by some I suspect this will too

arnaud
2016-11-29 21:28
hey, @ghaskins will you be at the hackfest next week?

ghaskins
2016-11-29 21:30
hey @arnaud if I am, I really should book something heh

ghaskins
2016-11-29 21:30
I live not too far away, though

ghaskins
2016-11-29 21:30
(MA ->NY)

arnaud
2016-11-29 21:30
cool, will be nice to meet you in person

garisingh
2016-11-29 21:37
@ghaskins - guest appearance in NYC for you next week?

jonathanlevi
2016-11-29 21:41
@garisingh - that would not be a bad idea!

arnaud
2016-11-29 21:41
that's what these are supposed to be about

arnaud
2016-11-29 21:43
you gotta hang out and have drinks to develop strong working relationships :wink:

arnaud
2016-11-29 21:44
it's all for the good of the project of course

garisingh
2016-11-29 21:59
project? there's a project going on? no one told me

arnaud
2016-11-29 22:05
:slightly_smiling_face:

arnaud
2016-11-29 22:05
seriously though, @ghaskins you should come

arnaud
2016-11-29 22:09
so, guys, I just tried to build the latest master version to check where things are at but I don't understand what I'm getting

arnaud
2016-11-29 22:11
when I tried launching the peer with peer node start --peer-chaincodedev

arnaud
2016-11-29 22:11
I get an error:

arnaud
2016-11-29 22:11
13:24:40.780 [committer] startDeliver -> INFO 063 Starting deliver service client 13:24:43.782 [committer] initDeliver -> ERRO 064 Cannot dial to 0.0.0.0:7050, because of grpc: timed out when dialing 13:24:43.783 [committer] startDeliver -> ERRO 065 Can't initiate deliver protocol [grpc: timed out when dialing]

arnaud
2016-11-29 22:11
but then it goes on anyway

arnaud
2016-11-29 22:12
13:24:50.972 [GossipStateProvider] antiEntropy -> DEBU 066 Current ledger height is the same as ledger height on other peers. 13:25:01.134 [GossipStateProvider] antiEntropy -> DEBU 067 Current ledger height is the same as ledger height on other peers.

arnaud
2016-11-29 22:12
I should say that I'm running vagrant

arnaud
2016-11-29 22:13
then I tried to stop it, hitting Ctrl C doesn't do shit

arnaud
2016-11-29 22:13
so I go to another shell and run "peer node stop"

arnaud
2016-11-29 22:14
this crashes

arnaud
2016-11-29 22:14
13:25:17.547 [msp] Setup -> INFO 00a MSP manager setup complete (config file /opt/gopath/src/github.com/hyperledger/fabric/msp/peer-config.json) 13:25:17.558 [nodeCmd] stop -> INFO 00b Stopping peer using grpc panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8fdf86] goroutine 1 [running]: panic(0xa7cac0, 0xc42000e0d0) /opt/go/src/runtime/panic.go:500 +0x1a1 http://github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb.(*ColumnFamilyHandle).Destroy(0x0) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb/cf_handle.go:25 +0x26 http://github.com/hyperledger/fabric/core/db.(*OpenchainDB).close(0xc42018d170) /opt/gopath/src/github.com/hyperledger/fabric/core/db/db.go:214 +0x33 http://github.com/hyperledger/fabric/core/db.Stop() /opt/gopath/src/github.com/hyperledger/fabric/core/db/db.go:82 +0x2d http://github.com/hyperledger/fabric/peer/node.stop(0x0, 0x4) /opt/gopath/src/github.com/hyperledger/fabric/peer/node/stop.go:76 +0x6cd http://github.com/hyperledger/fabric/peer/node.glob..func3(0x1088280, 0x10d1df8, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/peer/node/stop.go:49 +0x22 ...

arnaud
2016-11-29 22:15
interestingly it still stops the node.

arnaud
2016-11-29 22:15
but all of that doesn't seem quite right

arnaud
2016-11-29 22:15
@garisingh any idea?

garisingh
2016-11-29 22:17
well I need to fix the CTRL+C - I was looking at that - we know that's an issue

garisingh
2016-11-29 22:17
not sure about the rocksdb one - I had not seen that before

arnaud
2016-11-29 22:17
ok

arnaud
2016-11-29 22:30
it is totally reproducible on my env right now

ghaskins
2016-11-29 23:12

ghaskins
2016-11-29 23:12
@arnaud will def see if I can arrange that

nikileshsa
2016-11-29 23:20
@ghaskins thanks. will take a look

cypherzealot
2016-11-30 04:28
has joined #fabric-dev

hgabor
2016-11-30 10:06
having a gerrit slowdown...

mikezaccardo
2016-11-30 20:17
Hi, I’ve submitted a new example application for review [https://gerrit.hyperledger.org/r/#/c/2883/] — this is my first contribution to this project and my first time using Gerrit code review, so any feedback would be very much appreciated. Thanks!

yacovm
2016-11-30 20:40
nvp?

yacovm
2016-11-30 20:41
if you mean by non validator peer then this term isn't used in V1


ghaskins
2016-12-01 03:34
gossip/comm:TestParallelSend failure


yacovm
2016-12-01 05:02
It's always for 5611

yacovm
2016-12-01 05:02
I will try something today

yacovm
2016-12-01 05:02
Thanks

yaoguo
2016-12-01 07:44
@garisingh not sure about your "CTRL+C" problem. if you mean peer can quite by "CTRL+C", https://gerrit.hyperledger.org/r/#/c/2867/ is a fix.

garisingh
2016-12-01 10:42
@yaoguo - yes - that's the issue - ctrl+c does not currently kill the peer process on master

yaoguo
2016-12-01 10:47
@garisingh i explain the reason in https://gerrit.hyperledger.org/r/#/c/2867/ and fix it, need reviews

garisingh
2016-12-01 11:05
yep - we knew the reason and thanks for the fix - going to do a quick review and test

muralisr
2016-12-01 11:07
@garisingh let me know after the test please ? I have some time before getting to office and help +2

garisingh
2016-12-01 11:12
@yaoguo @muralisr - looks good and works like a charm

muralisr
2016-12-01 11:12
perfect. let me look

muralisr
2016-12-01 11:19
@yaoguo just curious … why did you need to add the `d.stopDeliver()` ?

muralisr
2016-12-01 11:19
(looked right .. but just curious as I wonder why it was not there in the first place.., ie, perhaps you ran into a specific problem while doing this work)

yaoguo
2016-12-01 11:32
@muralisr `d.stopDeliver()` to make line227 `d.client.Recv()` return connection error right away. or code will be blocked at Recv if no new message.

muralisr
2016-12-01 11:33
ah … so it _was_ missing

muralisr
2016-12-01 11:33
thanks much

muralisr
2016-12-01 11:35
merged. Thanks @yaoguo, @garisingh

garisingh
2016-12-01 11:36
thanks for this @yaoguo

yaoguo
2016-12-01 11:36
:grinning:

ephan
2016-12-01 14:35
has joined #fabric-dev

yacovm
2016-12-02 06:45

ceobco
2016-12-02 08:51
has joined #fabric-dev

ceobco
2016-12-02 08:51
Hello

jonathanlevi
2016-12-02 13:08
Hello and welcome @ceobco.

ceobco
2016-12-02 13:18
Hello @jonathanlevi

lesterpig
2016-12-03 17:15
has joined #fabric-dev

steven.landers
2016-12-04 02:04
has joined #fabric-dev

jaysa
2016-12-04 23:53
has joined #fabric-dev

nits7sid
2016-12-05 07:06
Is it possible to start only 3 peers on IBM bluemix and 1 on my Data center and get connected?

garisingh
2016-12-05 10:15
@nits7sid - you could connect a non-validating peer but there's really no purpose in doing that. You can't add a validating peer to the Bluemix setup - it's a fixed network config with 4 validating nodes

nits7sid
2016-12-05 11:12
Oh Can i purchase a IBM bluemix container and run peer on that and then connect to 3 peers in my Data centers. So a network would like 3 pees running in my data center and 1 on IBM bluemix

weeds
2016-12-05 15:01
We are at the Hyperledger Hackathan here in NY- IBM Binh Nguyen is presenting today--

weeds
2016-12-05 15:01
He thanked the community members for all their code contribusion- LSEG, CLS, JPMC, and so many others

weeds
2016-12-05 15:02
He did indicate there are two companies in production with the 0.6 version of the fabric.

weeds
2016-12-05 15:02
He indicated that there are many things we have learned

weeds
2016-12-05 15:02
that have been integrated into the new design

weeds
2016-12-05 15:02
Data and decisions remain with stakeholders (endorser model, multi-chain architecture)

weeds
2016-12-05 15:02
Plug-ability to enable fleibility in development and deployment ( Identity- MSP, Consensus, Data store)

weeds
2016-12-05 15:02
Transaction history on an Asset

weeds
2016-12-05 15:03
Native SDK- SDK spec for developers to implement in any language, where we have development occurring on Java, Node.js, Python and more to come

weeds
2016-12-05 15:03
Hardware Security model support- 2 implementations: modified, and unmodified PKSC11 for T-cert generation

weeds
2016-12-05 15:03
Access control on whho can query or submit transactions

weeds
2016-12-05 15:03
Upgradeable chaincode

weeds
2016-12-05 15:04
Binh inidcated given consensus is pluggable he would like to partner closely with intel to see what could plug into the fabric

weeds
2016-12-05 15:09
Binh indicated a lot of this capability is going to complete very soon... and that they will be giving a demo.

weeds
2016-12-05 15:11
Binh showed Organization peer 1.1, 1.2, and 13... and then organization peer 2.1, 22, 2.3,.. and an ordering service-- they are not connected at this point (except for peers in their own organization).

weeds
2016-12-05 15:12
Let's say members of 1.1, 1.2, and 1.3 and 2.1, 2.2, and 2.3 want to create a chain

weeds
2016-12-05 15:12
#./peer chain create <config file> ,.................... #./peer chain join <1.1, 1.2><configuration block>

weeds
2016-12-05 15:13
This org 1 peer tells which node they can connect to... node 1.3 is an anchor of the chain so that te orgs can connect to each other.

weeds
2016-12-05 15:14
These nodes then form the gossip group... the leader will then connect to the ordering service to receive data from that particular chain.

weeds
2016-12-05 15:14
Anchors have become 1.3, 2.3,... leaders were 1.1, 2.1

weeds
2016-12-05 15:14
Another Example.

weeds
2016-12-05 15:14
Chain 2 we want to create chain with 1.1, 1.3,2.2, 2.3

weeds
2016-12-05 15:15
You can do that,.. and then you can also add organization 3 as well if needed

weeds
2016-12-05 15:15
So How do you define a transaction?

weeds
2016-12-05 15:15
Transaction starts with a proposal and sent to a specific set of peers to get an endorsement.

weeds
2016-12-05 15:16
Once endorsement happens, you send to orderer and will organization transactions and send back to the peer

weeds
2016-12-05 15:16
Peer will validate the transaction and commit wit consensus

weeds
2016-12-05 15:16
-> Transaction transforms data, scoped by chaincode on ledger from which it operates

weeds
2016-12-05 15:16
-> Transaction types: chaincode configuration, and any custom. Each type is associated with a handler (system chaincode)

weeds
2016-12-05 15:17
application SDK-> endorse (TX) -> peers--> respond (endorse tx)--> application/sdk--> broadcast to the order on the specific chain--> put in sequence to blocks and send only back to the peers within that chain

weeds
2016-12-05 15:18
--->Transaction Flow inside a peer<----

weeds
2016-12-05 15:18
Application needs ability to control endorsement and validation logic

weeds
2016-12-05 15:18
- Each chaincode is associated with an endorsement (ESCC) and validation system chaincode (VSCC) when deployed

weeds
2016-12-05 15:19
- Default implementation: simple declarative language

weeds
2016-12-05 15:19
- ESCC signs the proposal response (endorsement)

weeds
2016-12-05 15:19
-VSCC validates the endorsement and MVCC

c0rwin
2016-12-05 15:19
@weeds is there video recording of the presentations? will somebody publish slides afterwards?

weeds
2016-12-05 15:20
--> Dynamic Multichain <--

weeds
2016-12-05 15:20
Chain is peers + ledger + ordering cahnnel

weeds
2016-12-05 15:20
Achain is isolates data and code to specific stakeholders

weeds
2016-12-05 15:20
What happens to the ledger- you can now replace te database

weeds
2016-12-05 15:21
The blocks , the # of transactions of blocks are still there-- all of tat is persisted in transaciton log on file database. From file, we extract out tat is related to state.

weeds
2016-12-05 15:21
You have read set and write set... that database is cached.. but not a database tat stores the transaction

weeds
2016-12-05 15:22
You can do sophisticated query depending on how you plug in the database... Level DB is limited to key value only,.. But we already have couchdb in master that as full query on JSON, which is much more powerful

weeds
2016-12-05 15:22
We also can keep track of another database for indexing-- maybe transaction 1, 2, 3 or give me block 5,.. you can go to index and extract it really quickly.

weeds
2016-12-05 15:23
Jim Zhang shows a demo

jonathanbmorley
2016-12-05 15:27
has joined #fabric-dev

bobbiejc
2016-12-05 15:47
has joined #fabric-dev

bfuentes
2016-12-05 15:53
has joined #fabric-dev

adnan
2016-12-05 16:03
has joined #fabric-dev

weeds
2016-12-05 20:33
@ c0rwin I assume they will publish slides

weeds
2016-12-05 20:33
the demo at least of fabric is in #playbacks channel


yacovm
2016-12-05 20:45
better ask in #ci-pipeline they should know that

jyellick
2016-12-05 20:45
Ah thanks, didn't know that channel existed, will check there

jjjjibm
2016-12-05 22:09
has joined #fabric-dev

jjjjibm
2016-12-05 22:19
@ry I get an error when I try to create an issue in Jira. It wants me to specify a resolution even though the issue is not yet created. Here is a screen shot:


jjjjibm
2016-12-05 22:21
I had a team member try this also, and she got the same result.

muralisr
2016-12-05 22:27
@jjjjibm just ran into that too… I used “Custom” under configure fields to unselect Resolution

muralisr
2016-12-05 22:27
a workaround :slightly_smiling_face:

ry
2016-12-05 23:07
I apologize - this is my fault entirely - I will fix it in the morning

muralisr
2016-12-05 23:20
@ry I just assumed a JIRA idiosyncracy

ry
2016-12-05 23:21
muralisr I changed the fabric workflow for cbf and it broke stuff.

muralisr
2016-12-05 23:21
ah ok

muralisr
2016-12-05 23:22
basically add a resolution field to bug and such sounds like except it added it to tasks too

muralisr
2016-12-05 23:22
?

ry
2016-12-05 23:22
yes

ry
2016-12-05 23:22
if anyone is a JIRA expert and wants to help maintain the fabric workflow I need help

muralisr
2016-12-05 23:22
(ducking hurriedly :slightly_smiling_face: )

muralisr
2016-12-05 23:23
I am just “user level” guy with JIRA

ry
2016-12-05 23:26
muralisr could you please try to file a bug against fabric and see if you can do it?

muralisr
2016-12-05 23:26
sure

muralisr
2016-12-05 23:28
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F3BKJULLF/pasted_image_at_2016_12_05_06_28_pm.png and commented: that list doesn’t seem right under a new bug ?

muralisr
2016-12-05 23:28
Resolution being a required field I have to select one of those

ry
2016-12-05 23:29
to create a bug, right?

muralisr
2016-12-05 23:29
right

muralisr
2016-12-05 23:29

ry
2016-12-05 23:29
please refresh the page and see if it's still there

muralisr
2016-12-05 23:29
good idea

ry
2016-12-05 23:29
if it isn't you don't need to file it

muralisr
2016-12-05 23:29
let me try that

ry
2016-12-05 23:30
no, I mean, I just deleted it

ry
2016-12-05 23:30
I expected that test to fail for you

muralisr
2016-12-05 23:31
i see

muralisr
2016-12-05 23:31
its not there

muralisr
2016-12-05 23:32
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F3BKLA6P9/pasted_image_at_2016_12_05_06_32_pm.png and commented: resolution is just a uneditable field now (like it was ?)

ry
2016-12-05 23:33
but you can file bugs now

ry
2016-12-05 23:33
so you're unblocked tonight

arnaud
2016-12-05 23:34
I can tell @ry is loving this...

ry
2016-12-05 23:35
I just wanted to go get dinner

arnaud
2016-12-05 23:36
I have another "small jira request" for you when you're done ;-)

ry
2016-12-05 23:36
hit me

arnaud
2016-12-05 23:37
No I'm just pulling your chain

muralisr
2016-12-05 23:43
ah there's the @arnaud style :slightly_smiling_face:

arnaud
2016-12-05 23:50
@muralisr where are you? We're missing you here

muralisr
2016-12-05 23:51
Arnaud, I’m missing it too … what a great gathering! … but next time :slightly_smiling_face:

dinesh_rivankar
2016-12-06 05:02
has joined #fabric-dev

kansi
2016-12-06 09:54
has joined #fabric-dev

nits7sid
2016-12-06 12:12
Hi. What are the minimum hardware specs required for setting up a single peer without vagrant?

garisingh
2016-12-06 12:29
@nits7sid - of course it will all depend on how many chaincodes, transaction rate, etc, but something like 1 CPU / 2GB RAM should work

chaitanya
2016-12-06 14:38
has joined #fabric-dev

chaitanya
2016-12-06 14:50
In the example given at https://github.com/hyperledger/fabric/blob/v0.6/examples/chaincode/go/asset_management_with_roles/asset_management_with_roles_test.go, the deploy method is bound to the chaincode setup by the `go initAssetManagementChaincode()`, right? What I have, is a set of chaincodes that need to be run one after another, and I need to test for Attribute Based Access Control on one of them. This would require that I deploy multiple chaincodes. Can someone point me to how I should go about it?

jonathanbmorley
2016-12-06 16:08
Hi folks -- trying to "make peer" and it downloaded the image and got stuck extracting... 370.9 MB / 400 and something. Sat there for an hour, so I killed it. Will try again. Any ideas?

jonathanbmorley
2016-12-06 16:15
Maybe that was a bad idea:

jonathanbmorley
2016-12-06 16:15
vagrant@hyperledger-devenv:v0.2.1-da16559:/opt/gopath/src/github.com/hyperledger/fabric$ make peer mkdir -p build/image/ccenv/payload cp build/docker/gotools/bin/protoc-gen-go build/bin/chaintool build/goshim.tar.bz2 build/image/ccenv/payload cp: cannot stat 'build/docker/gotools/bin/protoc-gen-go': No such file or directory Makefile:191: recipe for target 'build/image/ccenv/payload' failed make: *** [build/image/ccenv/payload] Error 1

jonathanbmorley
2016-12-06 16:32
Did vagrant destroy and then re-ran the commands. Made it a bit farther but stalled at 384 this time. Thinking it's a memory limitation in the VM

ghaskins
2016-12-06 17:01
hi @jonathanbmorley is it downloading a docker image?

jonathanbmorley
2016-12-06 17:53
Hi @ghaskins, it downloaded the image and got stuck extracting. I've tried three times -- I think I'm out of memory on my laptop

jonathanbmorley
2016-12-06 17:53
This machine has 4GB and task manager shows 0 free when extraction stalls

ghaskins
2016-12-06 17:53
yeah, that could be the problem

jonathanbmorley
2016-12-06 17:54
I tried safe mode; however, Vagrant won't spin up with safe mode.

ghaskins
2016-12-06 17:54
ive also seen weirdness on my setup where the VM will hang until you do something peripheral

ghaskins
2016-12-06 17:54
like, login from another window and do something that generates activity, like run "top"

ghaskins
2016-12-06 17:54
then it will start working again...I dont know what it could be

jonathanbmorley
2016-12-06 17:54
I'll give that a shot in a few minutes. Thanks!

ghaskins
2016-12-06 17:54
but in your case, the fact that you have so little memory is suspect

ghaskins
2016-12-06 17:55
are you working with mainline?

ghaskins
2016-12-06 17:55
if so, note that vagrant is more or less optional for most things if you have a docker environment (such as docker-for-mac

ghaskins
2016-12-06 17:56
so, if you are memory constrained, that might work better for you

jonathanbmorley
2016-12-06 17:56
I'm on Windows, not Mac.

ghaskins
2016-12-06 23:02
That was a for-example

ghaskins
2016-12-06 23:02
Comments would apply equally to any platform that supports docker

newdev2524
2016-12-07 03:21
has joined #fabric-dev

newdev2524
2016-12-07 03:21
Hi, after I brought up a new peer node while other nodes were running, it seemed the chaincode previously deployed in other nodes didn't sync to the new peer node. Does anyone know what the problem is?

nvlasov
2016-12-07 06:43
has joined #fabric-dev

alexliusch
2016-12-07 13:00
has joined #fabric-dev

alexliusch
2016-12-07 13:02
@simon @keithsmith can i ask a question?how to solve the problem that CA certificates expired after three month without emptying all existed data?

jonathanlevi
2016-12-07 15:17
___ @alexliusch: of course you can :wink:

jonathanlevi
2016-12-07 15:18
It depends on the version you work with, but you can restart the “CA generating service/process”, without affecting the “chain”.

jonathanlevi
2016-12-07 15:18
I’m being a bit careful here though, in terms of what’s “existing data”….

jonathanlevi
2016-12-07 15:19
There is a much nicer separation of the storage in v1.0, along with a better clarity in terms of a ‘certDB’… etc.

jonathanlevi
2016-12-07 15:21
BTW: when you wrote `CA certificates` I assumed that you are asking about the “Server” CA certificates and not the ECerts or TCerts ?

jonathanlevi
2016-12-07 15:22
We can also move this discussion to #fabric-cop.

alexliusch
2016-12-07 15:23
thx!i’ll try it, the 'existing data ‘ means data on chain:grin: forgive my poor English

alexliusch
2016-12-07 15:25
yeah i asked about CA server,i ll join that channel @jonathanlevi

jonathanlevi
2016-12-07 15:25
Not a problem (English or otherwise). I am just trying to clarify, so that I do not misunderstand you/or mislead you.

jonathanlevi
2016-12-07 15:26
Sure, please do. A lot is going on there, and these are good days to provide feedback as we merge related stuff to the master branch daily. Let us know.

alexliusch
2016-12-07 15:27
okay:slightly_smiling_face:

martijnwouters
2016-12-07 15:36
has joined #fabric-dev

joshhus
2016-12-07 19:02
Error message inquiry ...

tylerkeen
2016-12-07 19:52
has joined #fabric-dev

t-watana
2016-12-08 00:22
has joined #fabric-dev

harsha544
2016-12-08 03:29
has joined #fabric-dev

humblealex
2016-12-08 09:43
hi all, I have two questions:

humblealex
2016-12-08 09:44
1. when I push a change to gerrit, should I add reviewers manually, or just wait for someone to do the assignment?

humblealex
2016-12-08 09:45
2. Is fabric v0.6 still open for changes?

humblealex
2016-12-08 09:45
very much appreciated if someone can provide the answers

c0rwin
2016-12-08 09:48
@humblealex there `cr-fabric` review group you can add so people will get notified about your CR and I do not think that v0.6 still open for new changes.

humblealex
2016-12-08 09:50
@c0rwin thank you very much, I will try to do that:)

trueter
2016-12-08 11:12
has joined #fabric-dev

bercinho
2016-12-08 12:37
has joined #fabric-dev

bercinho
2016-12-08 12:38
Hi All, anyone knows where too lookup information regarding codechain integration? when I don´t want to push data into the blockchain worls state, but rather have chaincode acess data via external serices? (this especailly becomes complex with real time data, like Pricing) ... I am aware of Oracles by Ethereum (SW, HW) and Cryplets from Microsoft, but what is the de-facto standard for Hyperledger?

bfuentes
2016-12-08 13:24
@bercinho well, normally it should be done by the chaincode. If you do it externally, no problem but there is anything to do with Hyperledger development

bfuentes
2016-12-08 13:25
we do not trust the caller by default

bfuentes
2016-12-08 13:25
he has to sign all what he does, and he is known by the CA

bercinho
2016-12-08 13:34
Hi Benjamin, what I meant is that the chaincode execution can not only rely on data within the Blockchain World State, but it needs external data. There are tons of use cases for this. One way to solve this is to have external data pushed down to the blockchain (once it changes, periodically or whatsoever). But in cases when this is not possible the chaincode should be able to reach out for data. For Ethereum Smart Contracts they introduced the concept of Oracles, and Microsoft provides the Cryplet architecture to deal with this having supprot from Intel via enclaves. There must be some pattern / guideline how to deal with this in case of Hyperledger allowing chaincode to reach out for external data. I do understand the problem that this has to be consistent over all Peers and should result with collecting the same data.

ahmedelhajji
2016-12-08 13:36
has joined #fabric-dev

elli
2016-12-08 13:45
has joined #fabric-dev

elli
2016-12-08 13:50
@bercinho, you are right: When there is a need for the chaincode to obtain information from external resources you would either need to have some "trusted entities" that are allowed to post announcements of this info occasionally to the blockchain, or you would need to have "oracles", i.e., dedicated entities trusted by the chaincode(s), and that the chaincode could query.

elli
2016-12-08 13:52
Up to version 0.6, the latter method could cause issues, as having two validators receiving different answer from the oracle (which can happen in cases of answers, whose value change in time) would bring the system potentially to an inconsistent state.

elli
2016-12-08 13:53
With the new architecture though we are not in this situation; while inconsistent responses may lead to difficulties on the client side, to have a proposal endorsed, as soon as endorsements (satisfying the endorsement policy of the chaincode) are obtained, the system cannot be brought to inconsistent state.

elli
2016-12-08 13:53
[At least with the default ESCC/VSCC provided by the fabric]

bercinho
2016-12-08 13:55
ok, so with Fabric v1 we should handle choosing between inconsistent results when simulating the chaincode execution as part of the endorsement policy?

elli
2016-12-08 13:56
My impression is that through the docker configuration chaincodes can indeed connect to external resources as of now, but adding @binhn , @muralisr to confirm this.

elli
2016-12-08 13:56
With the new architecture that fabric v1 is implementing, the execution takes place before the addition of the transaction to the ledger.

bercinho
2016-12-08 13:57
with v0.6 we should simply keep pushing down the data to the Blockchain World State, is there any support for integration with IPFS or BigChainDB for Hyperledger?

elli
2016-12-08 13:57
The client sends "tx-proposals" to the endorsers who are listed as "responsible for that chaincode's execution", and try to obtain signatures of these endorsers on the same result.

bercinho
2016-12-08 13:57
it would be better to push down the data into these distributed file system, DB instead of the Blockchain World State

elli
2016-12-08 13:58
Result here would be the input and output (i am guessing this you would still need to track through some fabric state).

elli
2016-12-08 14:00
Ok, i will need to look into the bigchaindb system ( I havent had the time to do so far unfortunately), and get back to you. Perhaps @dave.enyeart has already an answer on this, or @vukolic .

bercinho
2016-12-08 14:00
Thanks Elli!

elli
2016-12-08 14:01
Overall though you need read-sets and write-sets of the state associated to a tx to refer to an external db, and not refer to the HPL state (?)

bfuentes
2016-12-08 14:02
@bercinho if you want to talk about interaction with external systems, as we are in a distributed network, I advise you to set a proxy to deal with non determinstic problems

bfuentes
2016-12-08 14:03
a blockchain is not a DB system, it is a distributed application

bfuentes
2016-12-08 14:04
the World State is the statefull and validated part of Hyperledger

bfuentes
2016-12-08 14:04
does not work like Bitcoin on this point

bercinho
2016-12-08 14:06
The question is does my distributed application have to own all the data that influences it´s behavior or we might have external data it might reach out to (pull) or be pushed into it´s scope.

bfuentes
2016-12-08 14:09
@bercinho very hard to answer, depends on your use case

bfuentes
2016-12-08 14:09
just share what it should be shared by all and need trust

bercinho
2016-12-08 14:10
when we have to push all data into the World State, then it might grow exponentially if my external data need & change frequency is really high why I was thinking to stage such data in an IPFS or BlockchainDB; if I can somehow call out via trusted proxies (Oracles, Cryplets) to maintain a deterministic, consistent & trusted response what is the pattern to do so (how do I do this from a chaincode running in a Docker?) ...

bfuentes
2016-12-08 14:10
yep

bfuentes
2016-12-08 14:10
for real time purpose, it can be problematic

bercinho
2016-12-08 14:11
I am looking into Energy Trading use case

bercinho
2016-12-08 14:11
:slightly_smiling_face:

bfuentes
2016-12-08 14:11
if your transactions are a big volume

bfuentes
2016-12-08 14:11
maybe, better to store an average /month

bfuentes
2016-12-08 14:11
as a trustable declaration

bfuentes
2016-12-08 14:11
otherwise, store very little data

bfuentes
2016-12-08 14:12
on each transaction

bfuentes
2016-12-08 14:12
but keep in mind

bfuentes
2016-12-08 14:12
you have blocks - and on the other side - World State

bfuentes
2016-12-08 14:12
this is 2 separated things

bfuentes
2016-12-08 14:13
maybe in World State, you can store only the current "count"

bfuentes
2016-12-08 14:13
that is updated at each transaction

bfuentes
2016-12-08 14:13
on this way, the WorldState is very light

bfuentes
2016-12-08 14:14
but if you want to keep all history … ? well you have still blocks to look up

bfuentes
2016-12-08 14:14
up to u

donjohnny
2016-12-08 14:21
has joined #fabric-dev

mdevilliers
2016-12-08 15:22
has joined #fabric-dev

nao
2016-12-08 17:47
has joined #fabric-dev

shinji
2016-12-08 20:51
has joined #fabric-dev

oliverledger
2016-12-08 21:15
has joined #fabric-dev

binhn
2016-12-08 23:35
@bercinho what would a transaction look like? if you have a lot of data (10s of MBs), I would suggest you store them somewhere else and use the hash on the transaction. The interaction with external systems is ideally done through the application, which then feeds the data into the chaincodes. In v1.0, chaincode may call out but its tricky to ensure deterministic result from external system. Also access to those external systems is another issue.

walker
2016-12-09 20:20
has joined #fabric-dev

yuwei
2016-12-10 14:21
has joined #fabric-dev

ruslan
2016-12-10 20:30
has joined #fabric-dev

darije.ramljak
2016-12-11 21:55
has joined #fabric-dev

mdavid
2016-12-13 00:46
has joined #fabric-dev

zhoupeiyuan
2016-12-14 04:38
has joined #fabric-dev

kenzhang
2016-12-14 04:47
has joined #fabric-dev

phoolet
2016-12-14 08:51
has joined #fabric-dev

phoolet
2016-12-14 09:19
Hi, I started with fabric only two days. I'm very confused. I am trying to follow the instructions here: https://hyperledger-fabric.readthedocs.io/en/latest/Setup/Chaincode-setup/

phoolet
2016-12-14 09:19
When I'm trying to run

phoolet
2016-12-14 09:19
the command “make membersrvc && membersrvc” i keep getting this error : make: *** No rule to make target 'membersrvc'. Stop.

phoolet
2016-12-14 09:20
I'm using the 0.6 v

baohua
2016-12-14 09:20
aha, pier, you may need the 0.6 branch code when using the inherent membersrvc

jonathanlevi
2016-12-14 09:20
From which directory are you running it?

phoolet
2016-12-14 09:20
favric

phoolet
2016-12-14 09:20
fabric directory

jonathanlevi
2016-12-14 09:20
@phoolet: what’s your “pwd"

baohua
2016-12-14 09:20
cd $GOPATH/src/github.com/hyperledger/fabric make membersrvc

jonathanlevi
2016-12-14 09:21
(show us the output, please) Also, `ls -l`

phoolet
2016-12-14 09:21
sorry, I don't know what is pwd

phoolet
2016-12-14 09:21
ok

jonathanlevi
2016-12-14 09:21
Can you please execute/run `pwd` [ENTER] :wink:

phoolet
2016-12-14 09:23
ok sorry :grinning:

jonathanlevi
2016-12-14 09:23
NP (no problem)

baohua
2016-12-14 09:25
:+1:

phoolet
2016-12-14 09:43
@jonathanlevi Ok works, sorry I had installed the version 1, now i have v0.6

sarkoi
2016-12-14 12:37
has joined #fabric-dev

tuand
2016-12-14 14:49
have a problem on jenkins https://jenkins.hyperledger.org/job/fabric-verify-x86_64/4067/ ... a unit test works fine on my local vagrant but fails in jenkins ? is there a channel I can go to ask for help ?


tuand
2016-12-14 14:55
right

yacovm
2016-12-14 14:58
well

yacovm
2016-12-14 14:58
you only have ca with lowercase

yacovm
2016-12-14 14:59
not with uppercase

yacovm
2016-12-14 14:59
I assume in your local FS you have that?

yacovm
2016-12-14 14:59
and on gerrit you don't?

tuand
2016-12-14 14:59
which ca ? test-ca-cert ?

yacovm
2016-12-14 15:00
yeah

yacovm
2016-12-14 15:00
I'm talking about the file

tuand
2016-12-14 15:00
no diff between local fs and gerrit

yacovm
2016-12-14 15:00
certFile, _ = ioutil.ReadFile("./test-CA-cert")

yacovm
2016-12-14 15:00
well I cloned the PR

yacovm
2016-12-14 15:00
and I don't see a test-CA-cert, only a test-ca-cert

tuand
2016-12-14 15:02
hmmm ... my gerrit says test-ca-cert


yacovm
2016-12-14 15:03
no, you also have test-CA-cert there

tuand
2016-12-14 15:03
argh ! i see it now

yacovm
2016-12-14 15:03
aren't you late for your scrum?

yacovm
2016-12-14 15:03
oh right

yacovm
2016-12-14 15:03
Wednesday

tuand
2016-12-14 15:03
brain fart .... thanks yacov ... still don't see why it worked on my vagrant

yacovm
2016-12-14 15:03
like I said

yacovm
2016-12-14 15:04
check you don't accidentally have the test-CA file or something locally

tuand
2016-12-14 15:04
one less meeting on wed :wink:

yacovm
2016-12-14 15:04
ok, glad I could help

ry
2016-12-14 16:03
tuand yacovm also check to make sure the filesystem isn't folding case (windows or mac os may not respect case depending on options)

tuand
2016-12-14 16:05
that sounds right ... i'm running vagrant on mac

py
2016-12-15 07:33
has joined #fabric-dev

kamo
2016-12-15 13:58
has joined #fabric-dev

vladislav_zolotarev
2016-12-15 14:49
has joined #fabric-dev

vladislav_zolotarev
2016-12-15 14:49
Hello! I am looking for the latest code possible for fabric project. I heard that there is a 1.0 ongoing development version? Is that the master I can see on github? Makefile states that it is 0.7.0 version

tuand
2016-12-15 14:51
master branch has the latest ... design docs are at https://wiki.hyperledger.org/community/fabric-design-docs

vladislav_zolotarev
2016-12-15 14:53
Thank you.

vladislav_zolotarev
2016-12-15 14:55
Do you happen to now, whether the 'Confidentiality' change is already present in the master branch?

d.baranov
2016-12-15 16:01
has joined #fabric-dev

anya
2016-12-15 19:07
@anya has left the channel

garisingh
2016-12-16 11:28
@vladislav_zolotarev - ` Do you happen to now, whether the `Confidentiality' change is already present in the master branch?` - can you be a bit more specific? What exactly are you looking for?

vladislav_zolotarev
2016-12-16 11:40
@garisingh I am talking about the cryptographic feature that allows peers to validate transactions based on additional transaction hash, so that transactions cam be anonymous.

divyank-sk
2016-12-16 15:19
has joined #fabric-dev

yacovm
2016-12-16 21:57
Where can I find information regarding the anchor peers (the special peers that are related to JoinChannel messages)?

bercinho
2016-12-19 09:28
Gents, why is this moved to graveyard? https://jira.hyperledger.org/browse/FAB-22

bercinho
2016-12-19 09:28
is there any plan to manage the lifecycle of chaincodes?

bercinho
2016-12-19 09:30
also does anyone know how we can view the blockchain in hyperledger? to see past historical transacitons?

bfuentes
2016-12-19 09:34
i think the focus on this feature is for V1.0

weeds
2016-12-19 12:56
@bercinho https://gerrit.hyperledger.org/r/#/c/3389 implements a usable/testable version of upgrade (happy path will work). This just got checked in recently. The chaincode is uniquely identified by (chain name, chaincode name). With upgrading support, we need to add the version number into the id generation- which is being worked (Murali might have already checked in already, but unclear)

bercinho
2016-12-19 12:57
@weeds thanks a lot, will check it out right away! :slightly_smiling_face:

weeds
2016-12-19 12:58
@bercinho one of the things that is getting worked on is to add couchdb to help more easily see past historical transactions. The developers working on this are on fabric-ledger-dev. I think they are looking for input on API interfaces as they are working through that.

weeds
2016-12-19 13:00
@vladislav_zolotarev please note when working with version 1.0 out of master there are a couple of sites that are useful. Design docs are here https://wiki.hyperledger.org/community/fabric-design-docs . There are also some instructions that they have been posting on how to get master running at that site. Also on you tube they have been posting playbacs.

zws
2016-12-19 13:01
has joined #fabric-dev

weeds
2016-12-19 13:02
@bercinho Also for the Couchdb work,.. you can go to the main design wiki https://wiki.hyperledger.org/community/fabric-design-docs, follow the link to the Ledger design. There you will find design charts that might answer some of your questions.

vladislav_zolotarev
2016-12-19 13:03
@weeds Thank you!

garisingh
2016-12-19 13:23
@bercinho - I think FAB-22 was moved their as it was a duplicate. You can see https://jira.hyperledger.org/browse/FAB-183

ahmedelhajji
2016-12-19 13:32
Hello, I would like an example of a docker-compose.yml file or use swarm to deploy multiple containers in several machines connected with swarm. For example 3 containers vp0 vp1 vp2.

muralisr
2016-12-19 14:47
@bercinho a usable version of upgrade waiting on the wings in https://gerrit.hyperledger.org/r/#/c/3389

muralisr
2016-12-19 14:48
@yaoguo and I plan to post a playback on it

bercinho
2016-12-19 15:15
@muralisr Thanks for the recommendation! I see this is for Fabric v1, so I guess for v0.6 we should not wait for such features anymore.

muralisr
2016-12-19 15:15
that would be correct :slightly_smiling_face: @bercinho

bercinho
2016-12-19 15:17
One more question: with the Blockchain Explorer you can indeed view the Ledger transactions, blocks, etc. but naturally everything encrypted. Is there any plan to provide a view on the blockchain regards to past transactions in a non-encrypted way for certain identities / roles , who actually triggered those transactions? So in case "robert" is firing couple of transactions via a ChainCode to the Blockchain, then he would be able to see all his historical transactions whenever requesting with his identitiy and approriate ECERT?

muralisr
2016-12-19 15:27
@bercinho I’d think that would be in control of the app in some form but it is reasonable to assume if "robert" has the right creds he should be able to see the transactions…. will refer to @ado @aso @garisingh to elaborate

bercinho
2016-12-19 15:31
Thanks @muralisr , it´s a feature we would really need for our PoC, and I do see it as a natural & quite useful functionality Hyperledger could easily provide via a new API ... I wouldn´t really like to trust and rely on the "external" app to store and persist these transactions.

muralisr
2016-12-19 15:32
@bercinho let me make sure .. you are referring to v1.0 correct ?

bercinho
2016-12-19 15:33
yes sure

bercinho
2016-12-19 15:34
v0.6 we started, but will migrate to v1.0

muralisr
2016-12-19 15:37
Ok. the security models are different in 1.0 …good to look at the details and differences. “fabric-crypto” channel would be a good resource

kostas
2016-12-20 05:48
On the latest master (HEAD `6e9073c`), if you `make peer` you get:

kostas
2016-12-20 05:48
```Step 3 : ADD payload/goshim.tar.bz2 $GOPATH/src/ Error processing tar file(bzip2 data invalid: bad magic value in continuation file): make: *** [build/image/ccenv/.dummy-x86_64-0.7.0-snapshot-6e9073c] Error 1```

kostas
2016-12-20 05:48
Something wrong on my end, or the master is indeed broken?

yacovm
2016-12-20 06:36
You're running mac right?

yacovm
2016-12-20 06:37
I think it's related with the tar binary or something

vladislav_zolotarev
2016-12-20 10:51
Hi. I am trying to figure out which would be the best API to use with fabric. Currently I went with REST API, but I have seen multiple statements that imply removal of REST API in the future, is that correct?

garisingh
2016-12-20 11:05
@vladislav_zolotarev - in Fabric V1 (the current code in the master branch), there are no REST APIs built-in to the peer for invoking / querying chaincode. You'll need to use the GRPC-based APIs although hopefully you can use one of the SDKs - Node, Java, Python

vladislav_zolotarev
2016-12-20 11:06
@garisingh Thank you, for clarification. I got a bit confused, since the latest documentation contains examples for running chaincode with CLI and REST options.

garisingh
2016-12-20 11:08
@kostas - the default `tar` included with OSX (and actually a few other utilities as well) are actually the BSD versions rather than the POSIX compliant versions used by *Nix operating systems. This link should help: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x/

garisingh
2016-12-20 11:09
@vladislav_zolotarev - yeah - those are based on the "current" version which is v0.6 (and it's fine to play around with v0.6 right now as well). We should be putting out more consumable versions of V1 in January

vladislav_zolotarev
2016-12-20 11:10
@garisingh Okay, thank you! I will consider available SDK options.

phoolet
2016-12-20 11:23
hi

garisingh
2016-12-20 11:25
hello

phoolet
2016-12-20 11:26
I have installed and use chaincode with 1 validato as a doc https://hyperledger-fabric.readthedocs.io/en/latest/Setup/Chaincode-setup/

phoolet
2016-12-20 11:27
and i depliy, invoke and query chaincode

phoolet
2016-12-20 11:27
I can use more validator?

kostas
2016-12-20 12:19
@garisingh @yacovm Gotcha, thanks for the pointer.

kostas
2016-12-20 12:30
If macOS's BSD tools are the culprit here, shouldn't this issue go away, if you decide to `make peer` from within the vagrant environment?

yacovm
2016-12-20 12:31
and it doesn't?

kostas
2016-12-20 12:45
Correct. Same error.

svasilyev
2016-12-20 12:51
has joined #fabric-dev

garisingh
2016-12-20 12:52
@kostas - I don't use Vagrant, but as I recall doesn't Vagrant mount the fabric src from your host system?

cbf
2016-12-20 12:52
@garisingh yes it does

garisingh
2016-12-20 12:52
perhaps you tried `make peer` locally first and then tried to spin up Vagrant? You might want to do a `make clean` in Vagrant first?

garisingh
2016-12-20 12:53
or `make clean` on your host before loading up Vagrant

cbf
2016-12-20 12:53
I generally make clean before a local build

garisingh
2016-12-20 12:53
(I could be off) :wink:

yacovm
2016-12-20 13:05
It does sound like what Gari said. .. But you can also do the make clean in vagrant IMO

ghaskins
2016-12-20 13:12
I concur with @garisingh, @kostas. I suspect you had residual build artifacts left over from your OSX build and a 'make clean' should fix it

kostas
2016-12-20 13:13
Roger, will do a `make clean` first.

garisingh
2016-12-20 13:28
@ghaskins - question / suggestion. So generally I build and test all my changes natively on my host (i.e. I just run `go test` directly on my host system) and then when things look good I then run `make unit-tests` locally (although I do forget sometimes) before submitted by patch for review There are of course times when `go test` runs fine locally but then when run in the context of `make unit-tests` it fails for one reason or another. `make unit-tests` takes a while to run so this is a pain (as others have stated). So one thing I've been doing locally is modifying `unit-test/run.sh` locally to only run the unit tests for the package(s) I've changed to quickly ensure that things work. So my question / suggestion - what do you think about possibly parameterizing `unit-test/run.sh` to optionally pass in the package you want to test rather than running unit tests for the whole fabric? It might be a nice convenience for people to quickly run their local change only in the "official" build/test environment?

ghaskins
2016-12-20 13:29
This has been on the "todo" list since that run.sh script went in

ghaskins
2016-12-20 13:29
if you want to tackle, greatly appreciated

ghaskins
2016-12-20 13:30
My thought was, we make it always accept the list of tests to run, and the default operation will acertain the list of all tests and pass that in

ghaskins
2016-12-20 13:30
that would pave the way to allow people to filter it to what they want

garisingh
2016-12-20 13:30
ok - cool

garisingh
2016-12-20 13:30
I'll take it on :wink:

ghaskins
2016-12-20 13:30
ty

ghaskins
2016-12-20 13:30
(I had been annoyed by this too, so I feel your pain

garisingh
2016-12-20 13:31
just wanted to check with the master of all things build first

ghaskins
2016-12-20 13:31
waiting for chaincode/core is, um, annoying

ghaskins
2016-12-20 13:31
heh

garisingh
2016-12-20 13:31
yep

yacovm
2016-12-20 13:32
Can't we make it run in parallel to the other unit tests and then combine the result? like scatter-->gather or something

yacovm
2016-12-20 13:32
just this test, it's like 11 min

ghaskins
2016-12-20 13:32
@yacovm I had tried to parallelize the tests in the past, it didnt work out so well

ghaskins
2016-12-20 13:33
but I also didnt have the time to fully dedicate to investigating why

ghaskins
2016-12-20 13:33
I would be in favor of moving chaincode/core in particular out of the "unit-test" path

ghaskins
2016-12-20 13:34
i.e. I think unit-tests should be quick (< 5min), anything else can be a later stage as part of an acceptance test

ghaskins
2016-12-20 13:34
e.g. behave, chaincode/core, etc

yacovm
2016-12-20 13:52
You mean each unit tests, not 5 min it total right?

yacovm
2016-12-20 13:52
All our tests are less than 90 seconds

ghaskins
2016-12-20 13:56
I mean I would like "make unit-tests" to take no longer than 5m total

ghaskins
2016-12-20 13:56
right now it takes about 20m IIRC

ghaskins
2016-12-20 13:56
mostly because of chaincode/core

ghaskins
2016-12-20 13:57
basically, for two reasons

ghaskins
2016-12-20 13:57
making them as painless as possible will encourage more people to run them locally before wasting CI resources

ghaskins
2016-12-20 13:58
and also, filtering out as many bad CRs as possible before we waste 20+ minutes of CI time...

ghaskins
2016-12-20 13:59
this will be particularly important for the resource constrained $arch's

ghaskins
2016-12-20 13:59
like P and Z, who only have ~3 builders

ghaskins
2016-12-20 14:00
if any random CR activity is going to squash 30+ minutes of a builders time, this could be a problem

yacovm
2016-12-20 20:52
@ghaskins speaking of CI squashing builder time, I have a PR and I have [ci-skip] and [skip-ci] in the commit message and it is still running unit tests. Any idea why?

yacovm
2016-12-20 20:53
``` [skip-ci] [ci-skip] ```

ghaskins
2016-12-20 20:53
@yacovm no idea, that is @ramesh's dept :wink:

yacovm
2016-12-20 20:53
But it's what I'm supposed to put there, right?

ghaskins
2016-12-20 20:53
I think the latter is right

yacovm
2016-12-20 20:53
I assume you know

ghaskins
2016-12-20 20:53
but I am not an expert

yacovm
2016-12-20 20:54
Yeah, I put both because I wasn't sure. will ask in ci-|. thanks

ghaskins
2016-12-20 20:54
np

weeds
2016-12-20 21:02
@suryavb95 @mohanv Surya any chance you can help yacovm or Ghaskins - see above.

suryavb95
2016-12-20 21:02
has joined #fabric-dev

mohanv
2016-12-20 21:02
has joined #fabric-dev

garisingh
2016-12-20 21:40
@yacovm - what exactly are you trying to do? Meaning you want to have a PR accepted / merged without it having to pass CI?

yacovm
2016-12-20 21:41
lol what?

yacovm
2016-12-20 21:41
The opposite

yacovm
2016-12-20 21:41
I have a WIP PR

yacovm
2016-12-20 21:41
I don't want jenkins to waste resources on it

yacovm
2016-12-20 21:41
I added the tags that are supposed to make it skip unit tests, but it still runs them

garisingh
2016-12-20 21:42
you can try removing the job builder in the UI right after submitting? I think there's a small window of time where that works as well

yacovm
2016-12-20 21:43
In the gerrit UI or in jenkins?

yacovm
2016-12-20 21:43
I don't think I have permissions for anything, I'm not a maintainer

garisingh
2016-12-20 21:43
Gerrit UI - now I may have just gotten lucky when I did it that way but right be worth a shot while waiting for the CI folks to respond

yacovm
2016-12-20 21:43
How do I do that?

yacovm
2016-12-20 21:44
ah

yacovm
2016-12-20 21:44
the reviewer?

garisingh
2016-12-20 21:44
try deleting job builder from the reviewers - but as I said - it might not actually work - it may have been coincidence that it worked for me in the past

yacovm
2016-12-20 21:45
Tells me "Delete not permitted"

garisingh
2016-12-20 21:45
hmm - what's the PR?

yacovm
2016-12-20 21:46
I'm afraid to tell you that, it's... pretty big :wink:


garisingh
2016-12-20 21:46
ha - that was my guess

yacovm
2016-12-20 21:46
400 of it is pb.go though

garisingh
2016-12-20 21:46
I deleted job builder from the reviewers list

yacovm
2016-12-20 21:46
I asked in #ci-pipeline anyway

yacovm
2016-12-20 21:47
It was working long ago, that tag. Maybe there is a regression and they should fix it

ry
2016-12-20 21:47
please don't worry about it. let Jenkins do its thing

yacovm
2016-12-20 21:48
But I checked and it still ran the unit tests...

ry
2016-12-20 21:48
wasting Jenkins resources is super low priority. why are you worrying about this?

yacovm
2016-12-20 21:51
Oh, I thought we have a limited number of VMs at a time and if I submit a change set and all VMs are taken it means that if someone else submits it doesn't start building right away and delays the feedback. If you say it's low priority than it's low priority, no problem.

yacovm
2016-12-20 21:51
Just trying to be a good citizen and all

ry
2016-12-20 21:51
we are limited, but right now, we aren't close to that limit on the whole.

ry
2016-12-20 21:51
I'll see if the ci-skip plugin was dropped.

ry
2016-12-20 21:51
which is what I suspect happened.

yacovm
2016-12-20 21:52
I'm happy to hear that. I remember we had times in which jenkins was saying sometimes "waiting for a free worker" or something of that sort

ry
2016-12-20 21:53
looking at it, we have ci-skip version 0.0.2 installed and enabled, and there aren't any other versions available. I'll see if the logs shed any light

ry
2016-12-20 21:59
yacovm I have what I suspect is the answer, would you be willing to try it out?

yacovm
2016-12-20 22:00
I can't in the near 8 hours, I left my laptop at the office :confused: But I can try in the morning

ry
2016-12-20 22:00
if I update your CR is that OK?

yacovm
2016-12-20 22:00
sure

yacovm
2016-12-20 22:01
It's all yours

ry
2016-12-20 22:02

yacovm
2016-12-20 22:03
oh come on I can't believe I haven't tried that

ry
2016-12-20 22:03
shrugs

yacovm
2016-12-20 22:03
I should write this down or something

ry
2016-12-20 22:03
I did "git log | grep skip |more" and that's how I found it

yacovm
2016-12-20 22:04
Heh, good idea!

yacovm
2016-12-20 22:04
thanks!


yacovm
2016-12-20 22:05
Yeah I see

ry
2016-12-20 22:05
so it did schedule a build, but nothing happened, so I think the ci-skip plugin just kills the build

yacovm
2016-12-20 22:05
` Build is skipped through commit message.`

yacovm
2016-12-20 22:05
That's what it says

ry
2016-12-20 22:06
funny. it goes to all the work to spin up a minion just to get that log message and throw it away. I figured it would do something smarter

kostas
2016-12-21 03:23
On the very latest master (tip `784d260`), `make dist-clean` followed by `make unit-test` results in:

kostas
2016-12-21 03:23
```cd unit-test && docker-compose up --abort-on-container-exit --force-recreate && docker-compose down Recreating 62c448903d2a_62c448903d2a_62c448903d2a_62c448903d2a_62c448903d2a_unittest_vp_1 ERROR: for vp No such image: sha256:b487745fe4203a4330f120dc0ce2e66246559932d469159edfbdac2849e1ef1e ERROR: Encountered errors while bringing up the project. Makefile:102: recipe for target 'unit-test' failed make: *** [unit-test] Error 1```

kostas
2016-12-21 03:23
Is this expected?

ghaskins
2016-12-21 05:58
Try "cd unit-test && docker-compose down "

ghaskins
2016-12-21 05:59
Then try again

ghaskins
2016-12-21 05:59
It's a docker compose issue that is exacerbated by the clean

sergefdrv
2016-12-21 09:39
has joined #fabric-dev

yuryandreev
2016-12-21 14:56
has joined #fabric-dev

kostas
2016-12-21 15:13
@ghaskins: That seems to fix it, thanks.

kostas
2016-12-21 15:44
```+ protoc --proto_path=/opt/gopath/src/github.com/hyperledger/fabric/core/comm/testdata/grpc --go_out=plugins=grpc:/opt/gopath/src /opt/gopath/src/github.com/hyperledger/fabric/core/comm/testdata/grpc/test.proto /opt/gopath/src/test.pb.go: Permission deniedMakefile:223: recipe for target 'protos' failed make: *** [protos] Error 1```

kostas
2016-12-21 15:45
This is the output of `make protos` (preceded by `make clean`). Expected?

ghaskins
2016-12-21 16:15
@kostas something looks busted

ghaskins
2016-12-21 16:16
I wouldnt expect /opt/gopath/src/test.pb.go

kostas
2016-12-21 16:19
Note that this is the case even if I do `make dist-clean` first.

kostas
2016-12-21 16:20
I am not blocked because I can always run the `protoc` command directly, but I figured I'd bring this to your attention.

ghaskins
2016-12-21 16:30
ty, pls file JIRA if you dont mind

joshhus
2016-12-21 16:45
Please flag @joshhus when content on here is good for external v1.0 doc. Hard to keep track of all slack channels, thanks!

kostas
2016-12-21 19:29
@ghaskins: Gari cannot reproduce this on his machine, so I'm guessing it's just the result of an unsuccessful run on my end, and then a case of `make clean` (and `make dist-clean`) not cleaning up everything. I'll do a `vagrant destroy`, and take it from there.

kostas
2016-12-21 19:29
If the issue persists, I'll follow-up with a JIRA issue.

mohamoudegal
2016-12-21 19:32
has joined #fabric-dev

mohamoudegal
2016-12-21 19:34
Hi everyone.

mohamoudegal
2016-12-21 19:35
I recently started developing on Fabric tutorial “Learn Chain code” -github and I ran into a bug that I need help with.

mohamoudegal
2016-12-21 19:35
@mohamoudegal uploaded a file: https://hyperledgerproject.slack.com/files/mohamoudegal/F3HQ9GZ60/screen_shot_2016-12-21_at_11.45.24_am.png and commented: I inputted the right info from the credentials file on Bluemix, but I’m getting a syntax error message. Please advise.

emir-sk
2016-12-21 19:48
has joined #fabric-dev

atom
2016-12-21 20:24
has joined #fabric-dev

atom
2016-12-21 20:30
@jonathanlevi It was kind of rough. Seems most of the issues revolved around the hashtable package, and the native compiler setup it needs. As I fought through the errors, I had to install Python (2.7 version, as the 3.0 version didn't work), then I had to install the Windows 8.1 SDK, but that doesn't include the compiler that was needed, so I had to install Visual Studio 2013 Express edition. Previously I had set a npm config setting to try and use VS2015, so I had to reset that to be msvs_version=2015, so i had to reset that to 2013. Whew... Figuring out what was needed at each step consisted of some luck and a lot of google'n.

atom
2016-12-21 20:30
oh, btw... for folks not in the general channel, that's related to installing the hfc package from npm for the SDK-Demo project.

garisingh
2016-12-21 20:59
@atom - I guess we need to add https://github.com/felixrieseberg/windows-build-tools to the docs for hfc. This makes it a snap to install the prereqs required on Windows for installing / compiling node packages with native code

atom
2016-12-21 21:03
I believe I installed those as well :slightly_smiling_face:

atom
2016-12-21 21:03
thanks for reminding me so that I can update my notes. :slightly_smiling_face:

atom
2016-12-21 21:06
bummer... Now when I ry to run "node helloblockchain.js" I get the following error: Error: Cannot find module 'C:\Users\....\...\SDK-Demo\node_modules\grpc\src\node\extension_binary\grpc_node.node'

atom
2016-12-21 21:23
Gave a shot at updating to grpc@1.0.1 (latest).. seemed to get further on the 'node helloblockchain.js', but still threw an error: Enrolled admin sucecssfully events.js:160 throw er; // Unhandled 'error' event ^ Error at ClientDuplexStream._emitStatusIfDone (C:\Users\...\...\SDK-Demo\node_modules\hfc\node_modules\grpc\src\node\src\client.js:189:19)

jonathanlevi
2016-12-21 21:31
@atom First of all, thanks for this. I haven’t used Windows in quite a while, but I agree, we should collect this and document. Shall we try to summarize these steps together? I can give it a shot and run it by you...

jonathanlevi
2016-12-21 21:32
And then we’ll get someone else, who’s completely new to this (that would “the old you”, before going through this ;-))… and see if he/she can simply follow these steps.

atom
2016-12-21 21:34
@jonathanlevi Sounds good to me, at least once I get it actually running. :slightly_smiling_face: I'm recording my steps, and I'd like to retry the steps on a fresh machine to make sure I've got it right.

jonathanlevi
2016-12-21 21:35
Not a problem. We can iterate on it. I’m just trying to use the “momentum”, while you are at it… and capture this.

jonathanlevi
2016-12-21 21:36
It’s good feedback. Certainly.

atom
2016-12-21 21:36
I've set a reminder to circle back around on this next week (after the holiday and all)

jonathanlevi
2016-12-21 21:37
OK. If you don’t mind me Copying & Pasting this, I will quickly open a JIRA item….

jonathanlevi
2016-12-21 21:37
(Not legally binding :-))

atom
2016-12-21 21:38
not a problem at all.


jonathanlevi
2016-12-21 21:51
@atom: You can also update there, or continue here. (now, later, when you are back from hols, etc.) Thanks again, and sorry for the “experience” :wink:

atom
2016-12-21 21:52
Thanks. Will do.

kostas
2016-12-21 23:11

ghaskins
2016-12-21 23:12
ty, i just grabbed ownership

ghaskins
2016-12-21 23:13
thanks for the report, sorry for the trouble :wink:

kostas
2016-12-21 23:15
np, this is the main story behind my upcoming book, "How `make protos` stole Christmas"

ghaskins
2016-12-21 23:15
heh

ghaskins
2016-12-21 23:15
you are not blocked?

ghaskins
2016-12-21 23:16
IIUC

kostas
2016-12-21 23:16
I can always do `./scripts/compile_protos.sh` and work around this. (Thanks @yacovm.)

ghaskins
2016-12-21 23:16
cool

yacovm
2016-12-21 23:17
np

kostas
2016-12-21 23:17
(Note that this command doesn't seem to work on my Mac by the way.)

yacovm
2016-12-21 23:17
yeah the flags are too platform specific

ghaskins
2016-12-21 23:18
yeah, IIRC there are linux-isms in there...it should work natively from linux (like devenv) or (barring bugs) from "make protos" since that runs in a docker environment

ghaskins
2016-12-21 23:18
but native osx? probably not, and not likely to ever be the case unless there is pressure because of FAB-1468

kostas
2016-12-21 23:20
No pressure.

kostas
2016-12-21 23:20
Thanks for looking into it.

shakespeare
2016-12-22 03:00
has joined #fabric-dev

ashishkel
2016-12-22 03:25
Does Fabric 0.6 have the soft logout feature? Right now if we use the Delete API, it deletes the user from the user data store rite?

ashishkel
2016-12-22 03:25
This prevents the use of same login credentials in any subsequent logins,

ashishkel
2016-12-22 03:25
So there was a discussion of implementing a soft logout a while back I guess

dgorman
2016-12-22 09:37
has joined #fabric-dev

haixu
2016-12-22 10:00
has joined #fabric-dev

garisingh
2016-12-22 10:02
@ashishkel - TL;DR - no soft logout using the REST API if you use the REST API to register / login with a peer, you will only ever be able to "login" to that same peer and no other peer. If you "delete" the user via the REST API against that same peer, you'll never be able to use that user with any other peer. If you use one of the SDKs (Node, Java) to register a user, you can use that user with any peer.

ashishkel
2016-12-22 11:00
Java SDK has the support for the soft logout ? That's great news. It's planned or is it available in the current gerrit source?

vigneswaran.r
2016-12-22 11:06
has joined #fabric-dev

vigneswaran.r
2016-12-22 11:08
Hello, is there any way to tell the peer to stop/end the chaincode (thus freeing up the resources) when the chaincode is not needed anymore? I couldn't see such feature in v0.6 and not sure about v1.0. Thanks.

ghaskins
2016-12-22 13:11
@vigneswaran.r 1.0, I believe, will have full chaincode lifecycle (deploy, update, terminate)

ghaskins
2016-12-22 13:11
@muralisr ^^^

muralisr
2016-12-22 13:13
right @ghaskins .. @vigneswaran.r the first version of upgrade will be out soon

muralisr
2016-12-22 13:13
its already in master but a playback will be posted on usage

bercinho
2016-12-22 14:37
Gents, I see that shim-client-1.0.jar is compiled with Java v1.8 and also we should use 1.8 version when developping & testing ChainCode locally (gradle needs it as well), but inside the Docker Container for the Peers we have Java version 1.7

bercinho
2016-12-22 14:38
how to manage this version incompatbility?

bfuentes
2016-12-22 14:41
@bercinho I never had problems, are you using V0.6.1 official images ?

bercinho
2016-12-22 14:42

bercinho
2016-12-22 14:42
Yes sure, have a look

bfuentes
2016-12-22 15:02
what is the error ? It should run fine

benlewis
2016-12-22 15:25
has joined #fabric-dev

nits7sid
2016-12-22 15:29
I am using a table with 2 keys. Stub.GetRows() breaks when called with just the first key. Using v0.6

benlewis
2016-12-22 15:59
On v0.6, is there any framework for listening for/responding to events?

markparz
2016-12-22 16:29
If you are not subscribed to the hyperledger fabric channel on youtube already please go out and do so to receive automatic notifications…. Otherwise you might have missed another great video showing how to upgrade chaincode, thank you @yaoguo!! https://youtu.be/hlJmRKo8HXE

vigneswaran.r
2016-12-23 00:59
@ghaskins @muralisr Ok, thank you.

wjq
2016-12-23 02:53
has joined #fabric-dev

shakespeare
2016-12-25 23:50
"Connect to the anchor Peers and start discovery protocol using ecert ". Here "anchor peers" is mentioned. How to understand this phrase? Which kind of peers are called "anchor peer? Anybody can explain it for me, thanks.

yacovm
2016-12-26 00:33
@shakespeare where is this sentence from? got a link?

shakespeare
2016-12-26 00:49
@yacovm FabricNext-Community.pdf. From this document. Thanks

shrike
2016-12-26 15:32
has joined #fabric-dev

shrike
2016-12-26 15:38
Hi, is there any docs/posts/materials about how to approach to the problem of big data - what are restrictions (if any) of data kept in blockchain? what are guidances (if any) of what size of data can be kept in blockchain? And what to do if I need store bigger data?

weeds
2016-12-26 20:08
@bobbiejc Bobbie- anything that you can provide guidance on for @shrike (I think she is on vacation, but she would know- i would suspect she would be back at first of year.

shrike
2016-12-26 21:11
@weeds thanks. I'll be back on January )

jonathanlevi
2016-12-26 22:26
@shrike, while obviously I don’t have all the context and background regarding the use-case you are after...

jonathanlevi
2016-12-26 22:27
there are a few approaches for dealing with “big data” ( <— needs definition/clarification, e.g. how much data, what’s its frequency, size/volume, number of sources…. etc. but):

jonathanlevi
2016-12-26 22:27
the simpler way is probably to store hashes of the data on a blockchain. So that you need to store so much information.

jonathanlevi
2016-12-26 22:28
Again, I’m apologizing again, as i don’t even know what specific property (or feature that the blockchain provide) you are after…

jonathanlevi
2016-12-26 22:31
… but if it is a scheme where you need a “trusted” or “provable” timestamping mechanism, or needing to later on prove that you had the original at a specific time in the past… or if you have one of the common “commitment” or timed (and signed) schemes… the simpler approach is to have another repository for the data, and a corresponding blockchain transaction (on the chain).


makimaki18
2016-12-28 14:21
has joined #fabric-dev

garisingh
2016-12-29 11:00
@passkit - what issues are you having building Docker images from the master branch?

passkit
2016-12-29 11:01
has joined #fabric-dev

passkit
2016-12-29 11:07
Firstly the vagrant image was missing some python packages (sha3 and openssl I think)

passkit
2016-12-29 11:07
After installing those, everything was ok up until here:

passkit
2016-12-29 11:07

madhava
2016-12-29 11:08
has joined #fabric-dev

passkit
2016-12-29 11:08
Then for Kafka, may of the scenarios fail

passkit
2016-12-29 11:09

garisingh
2016-12-29 11:12
which make target were you using?

garisingh
2016-12-29 11:13
(BTW - what's your host operating system? With the current master branch, you should be able to build/run everything without Vagrant by simply using Docker)

garisingh
2016-12-29 11:15
if you just want to build the peer and orderer images, you should be able to just run: `make peer-docker` `make orderer-docker`

passkit
2016-12-29 11:15
I’m using Mac OSX

passkit
2016-12-29 11:17
target was dist-clean all

garisingh
2016-12-29 11:25
I'm pretty sure that many of the bdd tests still fail (it's a problem which will be addressed when most people get back from the holiday) I use Mac OSX myself. I basically just installed Docker for Mac and then just run everything locally on my Mac (i.e. I don't use Vagrant) `make unit-tests` works fine for me with the latest master `make peer-docker` and `make orderer-docker` also work for me as well

serinth
2016-12-29 22:13
has joined #fabric-dev

passkit
2016-12-30 01:44
Thanks - I started again with a clean setup and everything build ok natively.

madhava
2016-12-30 06:55
Hi All, when try to start and register the chaincode am getting below error

madhava
2016-12-30 06:55

madhava
2016-12-30 06:55
i tried with 7051 port also but still no luck

madhava
2016-12-30 06:56
and when i ran the netstat cmd

madhava
2016-12-30 06:56

madhava
2016-12-30 06:56
i don't see any listening ports but the peer is running

madhava
2016-12-30 06:57
please help me to resolve the issue

madhava
2016-12-30 07:15
in .yml file what would be the CORE_VM_ENDPOINT=unix:///var/run/docker.sock EP , am using unbutu

madhava
2016-12-30 07:45

madhava
2016-12-30 07:46
i pulled the fabric from git only but when i try to run peer cmd its says not found

madhava
2016-12-30 08:11
i pulled v0.6 fabric version only but still am getting same error

madhava
2016-12-30 08:11
please help me to resolve the issue

harsha544
2016-12-30 09:24
@madhava Let's resolve the problem step-by-step

harsha544
2016-12-30 09:24
is your peer and membersrvc running on the system ?

madhava
2016-12-30 09:26
Harsha yes both containers are running

madhava
2016-12-30 09:26

madhava
2016-12-30 09:27
am using docker not vagrant

harsha544
2016-12-30 09:31
Did you try make peer from $GOPATH/src/github.com/hyperledger/fabric/

madhava
2016-12-30 09:33
let me try, when i ran last time its says what is the target for make peer

madhava
2016-12-30 09:38
ran the cmd, it took around 5mins to execute it and am seeing error at the end

madhava
2016-12-30 09:38
# http://github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb exec: "gcc": executable file not found in $PATH # http://github.com/hyperledger/fabric/vendor/github.com/mattn/go-sqlite3 exec: "gcc": executable file not found in $PATH Makefile:176: recipe for target 'build/bin/peer' failed make: *** [build/bin/peer] Error 2

madhava
2016-12-30 09:45
Harsha, build folder got created but there is no peer under /bin folder

harsha544
2016-12-30 11:02
Looks like gcc isn't installed on your system. sudo apt install build-essential -y

madhava
2016-12-30 15:23
all, when i try to run chain code am getting below connection timeout error

madhava
2016-12-30 15:23
ubuntu@ip-20-0-4-206:~/work/src/github.com/hyperledger/fabric/build/bin$ ./peer chaincode deploy -n mycc -c '{"Args": ["init", "a","100", "b", "200"]}' 2016/12/30 15:20:55 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:7051: getsockopt: connection refused"; Reconnecting to {"0.0.0.0:7051" <nil>} 2016/12/30 15:20:56 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 0.0.0.0:7051: getsockopt: connection refused"; Reconnecting to {"0.0.0.0:7051" <nil>} Error: Error building chaincode: Error trying to connect to local peer: grpc: timed out when dialing

madhava
2016-12-30 15:23
please help me to fix the issue

madhava
2016-12-30 15:36
is there any fix for above issue

muralisr
2016-12-30 15:38
@madhava .. I assume you have the peer running ?

madhava
2016-12-30 15:40
yes its running and i chain code is also registered in peer

madhava
2016-12-30 15:41

madhava
2016-12-30 15:41
this is the current log of peer

muralisr
2016-12-30 15:41
how did the chaincode connect to the peer ?

madhava
2016-12-30 15:41
CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=172.17.0.3:7051 ./chaincode_example02

muralisr
2016-12-30 15:41
ok

muralisr
2016-12-30 15:42
can you try `CORE_PEER_ADDRESS=172.17.0.3:7051 ./peer chaincode deploy -n mycc -c '{"Args": ["init", "a","100", "b", "200"]}’`

madhava
2016-12-30 15:42
i used above cmd to register chain code

madhava
2016-12-30 15:42
sure

madhava
2016-12-30 15:43
Error: Error building chaincode: rpc error: code = 5 desc = open /var/hyperledger/production/crypto/client/ks/raw/eca.cert.chain: no such file or directory

madhava
2016-12-30 15:43
and in peer logs i see below error

madhava
2016-12-30 15:43

muralisr
2016-12-30 15:43
so now at least its getting thru

muralisr
2016-12-30 15:44
how are you running the peer ?

madhava
2016-12-30 15:44
hmm correct

madhava
2016-12-30 15:44
docker-compose up

muralisr
2016-12-30 15:44
sounds like you are running in secure mode

muralisr
2016-12-30 15:45
I’d modify the compose file to remove all security params

muralisr
2016-12-30 15:45
and try to get it working first

madhava
2016-12-30 15:45
ok


madhava
2016-12-30 15:47
do i need to follow this link?

muralisr
2016-12-30 15:48
well

muralisr
2016-12-30 15:48
I assume in your compose file you have something like ``` - CORE_PEER_PKI_ECA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TCA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054 - CORE_SECURITY_ENABLED=true - CORE_SECURITY_ENROLLID=test_vp0 - CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT```

muralisr
2016-12-30 15:48
I’d remove all those properties and start

madhava
2016-12-30 15:50
yes have like this

madhava
2016-12-30 15:50

madhava
2016-12-30 15:51
so will remove below entries and start the peer again, is that ok?

madhava
2016-12-30 15:51
- CORE_SECURITY_ENABLED=true - CORE_PEER_PKI_ECA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TCA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054

muralisr
2016-12-30 15:52
yes

muralisr
2016-12-30 15:52
that should be fine

madhava
2016-12-30 15:52
ok

muralisr
2016-12-30 15:52
lets try with that

madhava
2016-12-30 15:53
sure

madhava
2016-12-30 15:56
@muralisr , restarted peer after making changes to .yml file

madhava
2016-12-30 15:57
also i ran deploy cmd

madhava
2016-12-30 15:57
ubuntu@ip-20-0-4-206:~/work/src/github.com/hyperledger/fabric/build/bin$ CORE_PEER_ADDRESS=172.17.0.3:7051 ./peer chaincode deploy -n mycc -c '{"Args": ["init", "a","100", "b", "200"]}' Deploy chaincode: mycc

madhava
2016-12-30 15:58
its returned "Deploy chaincode: mycc"

muralisr
2016-12-30 15:59
what do you see on the chaincode terminal ?

madhava
2016-12-30 16:03

muralisr
2016-12-30 16:03
sounds you are in business

madhava
2016-12-30 16:03
:slightly_smiling_face: thank you but confused

madhava
2016-12-30 16:04
how can i expose chain code as micro services ep's

madhava
2016-12-30 16:04
can you please refer any document

muralisr
2016-12-30 16:08
well, first of all what you have done just now is working with the chaincode in “development mode”

muralisr
2016-12-30 16:08
the question really belongs to the deployment architecture for your use case.

madhava
2016-12-30 16:10
my use case is supply chain to see the complete audit trail

muralisr
2016-12-30 16:13
googling `hyperledger fabric supply chain` gets some interesting links

madhava
2016-12-30 16:14
sure

muralisr
2016-12-30 16:14
one approach that’ll get you familiarized with the fabric would be to build a chaincode that can be deployed on all the peers on your supply chain

muralisr
2016-12-30 16:15
the chaincode would contain the datastructures that would save the supply chain transactions

muralisr
2016-12-30 16:16
let me get you a more comprehensive chaincode than chaincode_example02

madhava
2016-12-30 16:17
that would be very helpful


madhava
2016-12-30 16:17
when the data gets stored in blockchain its stored in hash format right Murali?

muralisr
2016-12-30 16:18
not exactly “hash” … but if you - the chaincode developer - wants to store hash, you could

muralisr
2016-12-30 16:19
the above demo uses a lot of features a typical chaincode dev would need

muralisr
2016-12-30 16:19
while not “supply chain” I’m sure you would be able to use ideas from there

madhava
2016-12-30 16:21
yes correct, one small clarification, do i need to explicitly expose chain code as services or as shown in this link need to "http://hyperledger-fabric.readthedocs.io/en/latest/Setup/Chaincode-setup/#running-the-chaincode"

madhava
2016-12-30 16:21
<host:port>/chaincode

madhava
2016-12-30 16:21
or i just use <host:port>/chaincode

muralisr
2016-12-30 16:22
I assume you are referring to the REST interface ?

madhava
2016-12-30 16:23
yes correct

muralisr
2016-12-30 16:23
the REST service is supplied by the fabric for all chaincodes

muralisr
2016-12-30 16:24
you would provie chaincode ID along with invoke/query params to call your particular chaincode

madhava
2016-12-30 16:24
why am getting confused is, i did small POC on Eris ( Monax ) where i need to create smart contact deploy to a chain and then exposed rest API's using nodeJS

muralisr
2016-12-30 16:25
using the nodeJS SDK supplied by the fabric ?

madhava
2016-12-30 16:25
Monax is a other private blockchain platform

muralisr
2016-12-30 16:25
or did you write your own nodeJS app to talk to the fabric using the above REST interface ?

muralisr
2016-12-30 16:25
oh I see

muralisr
2016-12-30 16:25
not on fabric

madhava
2016-12-30 16:26
correct not on fabric, fabric i just started yesterday

muralisr
2016-12-30 16:26
ok

madhava
2016-12-30 16:26
so fabric itself will takecare of exposing chaincode as a rest API's

madhava
2016-12-30 16:27
is that my understanding correct?

muralisr
2016-12-30 16:27
in 0.6/0.7 you can use the aboce REST API

madhava
2016-12-30 16:28
ok

muralisr
2016-12-30 16:28
in the latest master REST support is removed in favor of a SDK based middle tier approach

muralisr
2016-12-30 16:29
the SDK provides APIs for you to interact with the fabric on which you can develop your application (fabric-sdk, fabric-sdk-dev provides more details)

muralisr
2016-12-30 16:30
but for now you could use the REST apis with 0.6/0.7 to familiarize with the fabric

madhava
2016-12-30 16:30
thank you Murali

muralisr
2016-12-30 16:31
but really, its just an alternative to `peer chaincode deploy…`, `peer chaincode invoke…` etc

muralisr
2016-12-30 16:31
absolutely

madhava
2016-12-30 16:31
ok

locusf
2017-01-02 07:25
has joined #fabric-dev

pushpalatha
2017-01-02 10:22
Hi All, i have a question regarding ledger database.. I want to get the details of column families var columnfamilies = []string{ blockchainCF, // blocks of the block chain stateCF, // world state stateDeltaCF, // open transaction state indexesCF, // tx uuid -> blockno persistCF, // persistent per-peer state (consensus) } Any idea??? plz help.

hanhzf
2017-01-02 11:05
Hi, I met some problem when building peer binary: vagrant@hyperledger-devenv:v0.0.10-e3b2d3f:/hyperledger$ make peer /opt/gopath/src/github.com/hyperledger/fabric/core/committer/txvalidator/validator.go:20:2: cannot find package "context" in any of: /opt/gopath/src/github.com/hyperledger/fabric/vendor/context (vendor tree) /opt/go/src/context (from $GOROOT) /opt/gopath/src/context (from $GOPATH) make: *** [build/bin/peer] Error 1 fabric/core/committer/txvalidator/validator.go is using "context", which is only available in Go1.7 Does that mean that in V1.0, the Golang dependency should be 1.7 or later ?

hanhzf
2017-01-02 11:07
Also I found this change-set that in fabric-baseimage, the Golang base image has been moved to v1.7.3 https://github.com/hyperledger/fabric-baseimage/commit/9a6c79924597aafd33bc53a493b601b5cd6c7887

garisingh
2017-01-02 12:14
@hanhzf - yes - we use Go 1.7.x for Fabric v1.0

hanhzf
2017-01-02 12:44
@garisingh thanks

karthikimg
2017-01-02 14:11
has joined #fabric-dev

sabaset
2017-01-02 19:16
has joined #fabric-dev

garisingh
2017-01-03 18:02
posting here as well

tzipih
2017-01-04 04:25
has joined #fabric-dev

bercinho
2017-01-04 09:06
Hi All, can someone tell me the different values for "type" and meaning within the REST API, see below an example for a deploy transaction:

bercinho
2017-01-04 09:06
{ "jsonrpc": "2.0", "method": "query", "params": { "type": 4, "chaincodeID":{ "name":"bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521" }, "ctorMsg": { "function":"query", "args":["farmer"] }, "secureContext": "lukas" }, "id": 5 }

bercinho
2017-01-04 09:07
I have seen type with "1" and "4" so far, but did not yet find explanation which stands for what


garisingh
2017-01-04 10:34
basically it's the type of chaincode being deployed - e.g. 1= golang, 4= java (which are the most widely used)

garisingh
2017-01-04 10:36
type 3 (CAR) uses the CAR packaging tool and type 2 (NODE) is for NodeJS in the future

bercinho
2017-01-04 12:14
Hi Garisingh, thanks for the response :slightly_smiling_face:

bercinho
2017-01-04 12:15
What I try to do is to deploy the Java Chaincode triggered via the REST API. This is my transaction:

bercinho
2017-01-04 12:15
{ "jsonrpc": "2.0", "method": "deploy", "params": { "type": 4, "chaincodeID": { "name": "JavaCDD", "path": "http://github.com/JavaCDD" }, "ctorMsg": { "function": "init", "args": [ "farmer", "10", "42" ] }, "secureContext": "lukas" }, "id": 1 }

bercinho
2017-01-04 12:16
I have the chaincode placed under "/opt/gopath/src/github.com/hyperledger/fabric/github.com/JavaCDD" on the Peer where I am submitting the command

bercinho
2017-01-04 12:17
actually I am running the Peer within a Docker Container and mapping a volume as below:

bercinho
2017-01-04 12:17
"vp3: image: hyperledger/fabric-peer net: hyperledger volumes: # tweak this to map a local developmnt directory tree into the container - /opt/gopath/src/github.com:/opt/gopath/src/github.com "

bercinho
2017-01-04 12:18

bercinho
2017-01-04 12:19
The response of the Rest Call is:

bercinho
2017-01-04 12:19
{ "jsonrpc": "2.0", "result": { "status": "OK", "message": "bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521" }, "id": 1 }

bercinho
2017-01-04 12:19
But Query fails after:

bercinho
2017-01-04 12:19
{ "jsonrpc": "2.0", "method": "query", "params": { "type": 4, "chaincodeID":{ "name":"bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521" }, "ctorMsg": { "function":"query", "args":["farmer"] }, "secureContext": "lukas" }, "id": 5 }

bercinho
2017-01-04 12:19
{ "jsonrpc": "2.0", "error": { "code": -32003, "message": "Query failure", "data": "Error when querying chaincode: Error:Failed to launch chaincode spec(Could not get deployment transaction for bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 - LedgerError - ResourceNotFound: ledger: resource not found)" }, "id": 5 }

bercinho
2017-01-04 12:19
so for some reason the deploy did not eventually work

bercinho
2017-01-04 12:22
Is this the correct deployment process?

bercinho
2017-01-04 12:23
Move chaincode (not yet built) to one of the Peers, submit a deploy transaction as above to this Peer and let Hyperledger take care of the rest?

bfuentes
2017-01-04 13:00
@bercinho see on peer logs, sometimes you will find the error there during the deployment phase

bfuentes
2017-01-04 13:01
if all is ok, do a : docker ps

bfuentes
2017-01-04 13:01
to see if your new container is running well

bfuentes
2017-01-04 13:01
the id is the same as the field “message” from the response

bercinho
2017-01-04 13:21
Hi Benjamin, Thanks for the feedback! The chaincode is not started up in a new container, though I receive the corresponding "chaincodeID" back, I have added the log of the peers, but can´t really see what´s going on ...


bfuentes
2017-01-04 13:29
are you using a secure network ?

bfuentes
2017-01-04 13:29
deploying java chaincode on V0.6 only work on a *non* secure network

bercinho
2017-01-04 13:31
what do you mean in terms of secure network?

garisingh
2017-01-04 13:32
@bfuentes - you mean with TLS disabled? (which is the default anyway)

bercinho
2017-01-04 13:32
TLS is disabled for sure, I did not configure that

bfuentes
2017-01-04 13:32
this env : - CORE_SECURITY_ENABLED=false

bercinho
2017-01-04 13:34
that setting is wrong in my setup, you are right!

bercinho
2017-01-04 13:34
this is what I have

bercinho
2017-01-04 13:34
vp0: image: hyperledger/fabric-peer net: hyperledger volumes: # tweak this to map a local developmnt directory tree into the container - /opt/gopath/src/github.com:/opt/gopath/src/github.com - /var/run/docker.sock:/var/run/docker.sock ports: - "7050:7050" - "7051:7051" - "7053:7053" environment: - CORE_PEER_ADDRESSAUTODETECT=true - CORE_VM_ENDPOINT=unix:///var/run/docker.sock - CORE_LOGGING_LEVEL=DEBUG - CORE_PEER_ID=vp0 - CORE_PEER_PKI_ECA_PADDR=10.43.185.247:7054 - CORE_PEER_PKI_TCA_PADDR=10.43.185.247:7054 - CORE_PEER_PKI_TLSCA_PADDR=10.43.185.247:7054 - CORE_SECURITY_ENABLED=true - CORE_SECURITY_ENROLLID=test_vp0 - CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT - CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=pbft - CORE_PBFT_GENERAL_MODE=batch - CORE_PBFT_GENERAL_N=6 #this gives access to the docker host daemon to deploy chain code in network mode #volumes: # - /var/run/docker.sock:/var/run/docker.sock external_links: - membersrvc command: sh -c "sleep 10; peer node start"

bfuentes
2017-01-04 13:34
try on a non secure network, you will not need to register a user when using REST API ;o)

bfuentes
2017-01-04 13:34
yep

bfuentes
2017-01-04 13:34
do it

bfuentes
2017-01-04 13:34
=> false

bfuentes
2017-01-04 13:35
it should work

bercinho
2017-01-04 13:35
ok, but can you confirm that Java Chaincode deployment will not work on a "secure network" ?

bfuentes
2017-01-04 13:35
normally when you do it on a secure network, you get a “Docker image null” ERR on the peer logs

bercinho
2017-01-04 13:36
how is that related?

bfuentes
2017-01-04 13:36
as the V0.6 java shim is not the current sprints , do it on a non secure. I am sure on the V1.0 this will be ok

bfuentes
2017-01-04 13:37
I do not know, I tried to find the cause without success

bfuentes
2017-01-04 13:37
no time for that , sorry :confused:

bercinho
2017-01-04 13:37
ok ok :slightly_smiling_face:

bercinho
2017-01-04 13:37
well it´s v0.6 anyway

bercinho
2017-01-04 13:38
so I should remove CORE_SECURITY_ENROLLID, CORE_SECURITY_ENROLLSECRET from the yaml?

bfuentes
2017-01-04 13:38
no more sec

bfuentes
2017-01-04 13:38
yep

bercinho
2017-01-04 13:38
ok, let me try :slightly_smiling_face:

bercinho
2017-01-04 13:38
thanks for advice

bfuentes
2017-01-04 13:39
i have this for a peer :

bfuentes
2017-01-04 13:39
environment: - CORE_PEER_DISCOVERY_PERIOD=300s - CORE_PEER_DISCOVERY_TOUCHPERIOD=301s - CORE_PEER_ADDRESSAUTODETECT=true - CORE_VM_ENDPOINT=unix:///var/run/docker.sock - CORE_LOGGING_LEVEL=DEBUG - CORE_PEER_PKI_ECA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TCA_PADDR=membersrvc:7054 - CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054 - CORE_SECURITY_ENABLED=false

bercinho
2017-01-04 13:49
It still fails ...

bercinho
2017-01-04 13:49
vp0_1 | 13:48:11.464 [rest] processChaincodeInvokeOrQuery -> ERRO 66d Error when querying chaincode: Error:Failed to launch chaincode spec(Could not get deployment transaction for bfdcbcf587970ffde3a078d8a897925280f8d50356 0185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 - LedgerError - ResourceNotFound: ledger: resource not found) vp0_1 | 13:48:11.464 [rest] ProcessChaincode -> INFO 66e REST successfully query chaincode: {"jsonrpc":"2.0","error":{"code":-32003,"message":"Query failure","data":"Error when querying chaincode: Error:Failed to launch chainc ode spec(Could not get deployment transaction for bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 - LedgerError - ResourceNotFound: ledger: resource not fou nd)"},"id":5}

bercinho
2017-01-04 13:51
I do however have this log for the deployment:

bercinho
2017-01-04 13:51
[36mvp0_1 | 13:47:55.439 [peer] sendTransactionsToLocalEngine -> DEBU 507 Sending message CHAIN_TRANSACTION with timestamp seconds:1483537675 nanos:439844076 to local engine vp0_1 | 13:47:55.443 [rest] processChaincodeDeploy -> INFO 50e Successfully deployed chainCode: bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 vp0_1 | 13:47:55.443 [rest] ProcessChaincode -> INFO 50f REST successfully deploy chaincode: {"jsonrpc":"2.0","result":{"status":"OK","message":"bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521"},"id":1} vp0_1 | 13:47:55.443 [consensus/pbft] ProcessEvent -> DEBU 510 Replica 0 batch main thread looping

bercinho
2017-01-04 13:52
there is no new docker engine started


bercinho
2017-01-04 14:39
Hi Benjamin, what is the consensus you are running? is it noops or pbft?

bfuentes
2017-01-04 14:46
noops

bfuentes
2017-01-04 14:46
better for testing

bercinho
2017-01-04 14:49
but does the java chaincode deployment work with pbft? did you try that?

bfuentes
2017-01-04 14:52
yes, it works

bfuentes
2017-01-04 14:52
just longer

bercinho
2017-01-04 15:14
Ok ,so now I have the engines up & running (noops, non-secure network)

bercinho
2017-01-04 15:15

bercinho
2017-01-04 15:15
but still problems with the Query transaciton

bercinho
2017-01-04 15:16
{ "jsonrpc": "2.0", "error": { "code": -32003, "message": "Query failure", "data": "Error when querying chaincode: Error:Failed to launch chaincode spec(Could not get deployment transaction for bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 - LedgerError - ResourceNotFound: ledger: resource not found)" }, "id": 5 }

garisingh
2017-01-04 15:16
your chaincode is not being successfully deployed

bercinho
2017-01-04 15:20
but is that not strange to have the engines up & running?

bercinho
2017-01-04 15:31
I do get from all the Peers this feedback in the log:

bercinho
2017-01-04 15:31
vp1_1 | 15:29:01.055 [consensus/noops] RecvMsg -> DEBU 2aa Handling Message of type: CONSENSUS vp0_1 | 15:29:01.060 [consensus/noops] RecvMsg -> DEBU 2d0 Sending to channel tx uuid: bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 vp0_1 | 15:29:01.060 [rest] processChaincodeDeploy -> INFO 2d1 Successfully deployed chainCode: bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 vp0_1 | 15:29:01.060 [rest] ProcessChaincode -> INFO 2d2 REST successfully deploy chaincode: {"jsonrpc":"2.0","result":{"status":"OK","message":"bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521"},"id":1} vp1_1 | 15:29:01.088 [consensus/noops] RecvMsg -> DEBU 2ad Sending to channel tx uuid: bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 vp3_1 | 15:29:01.759 [consensus/noops] handleChannels -> DEBU 2b0 Process block due to time

bercinho
2017-01-04 15:31
"Successfully deployed chainCode"

bercinho
2017-01-04 15:31
docker containers are running for the chaincode after deployment transaction

bercinho
2017-01-04 15:32

bercinho
2017-01-04 15:32
still I get an exception for the Query transaction

bercinho
2017-01-04 15:34
please note the strange random names of the containers

bercinho
2017-01-04 15:34
which are not aligned with the "bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521" chaincode id

bercinho
2017-01-04 15:35
can this be an issue?

bercinho
2017-01-04 15:39


yangtao76
2017-01-04 15:44
has joined #fabric-dev

bercinho
2017-01-04 16:04

bercinho
2017-01-04 16:04
ERRO[3665] Handler for POST /containers/dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521/kill returned error: Cannot kill container dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521: No such container: dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 ERRO[3665] Handler for DELETE /containers/dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 returned error: No such container: dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521 ERRO[3665] Handler for POST /containers/create returned error: No such image: dev-vp2-bfdcbcf587970ffde3a078d8a897925280f8d503560185a42d24d3b1df7a78b1910480ae29722a1e5bb8c01b7939d2a5efe8d4a1d8217ae3b3da119858769521:latest

bercinho
2017-01-04 16:05
somehow after the deploy transaction the Docker Images created for the Chaincode and the Docker Containers created out of these images don´t follow the expected naming

bercinho
2017-01-04 16:05
this seems to cause some problems

bercinho
2017-01-04 16:06
can you please confirm on how images supposed to be named and containers and why this problem might occur that the deploy transaction is not resulting with expected naming?

bercinho
2017-01-04 16:23
I also don´t find the chaincode within the Docker Containers created

bercinho
2017-01-04 16:25
# find . -name "JavaCDD.java" ./chaincode/src/main/java/com/ibm/JavaCDD.java

bercinho
2017-01-04 16:31
sorry I have to correct myself the chaincode is there and is running ... so the only problem might be with the Image & Container names?

bercinho
2017-01-04 17:02
vp0_1 | 16:36:12.319 [dockercontroller] deployImage -> ERRO 1b74 Error building images: The command '/bin/sh -c cd /root/chaincode && gradle -b build.gradle clean && gradle -b build.gradle build' returned a non-zero code: 1 vp0_1 | 16:36:12.319 [dockercontroller] deployImage -> ERRO 1b75 Image Output: vp0_1 | ******************** vp0_1 | Step 1 : FROM hyperledger/fabric-javaenv:x86_64-0.6.1-preview vp0_1 | ---> a932c5e9f394 vp0_1 | Step 2 : COPY src /root/chaincode vp0_1 | ---> Using cache vp0_1 | ---> f097196847ea vp0_1 | Step 3 : RUN cd /root/chaincode && gradle -b build.gradle clean && gradle -b build.gradle build vp0_1 | ---> Running in ea4b244ae39e vp0_1 | :clean vp0_1 | vp0_1 | BUILD SUCCESSFUL vp0_1 | vp0_1 | Total time: 20.141 secs vp0_1 | vp0_1 | This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.12/userguide/gradle_daemon.html vp0_1 | :compileJava/root/chaincode/src/main/java/com/ibm/WeatherObservationResponse.java:3: error: package com.fasterxml.jackson.annotation does not exist vp0_1 | import com.fasterxml.jackson.annotation.JsonIgnoreProperties; vp0_1 |  ^ vp0_1 | /root/chaincode/src/main/java/com/ibm/WeatherObservationResponse.java:5: error: cannot find symbol vp0_1 | @JsonIgnoreProperties(ignoreUnknown = true) vp0_1 |  ^ vp0_1 |  symbol: class JsonIgnoreProperties vp0_1 | /root/chaincode/src/main/java/com/ibm/WeatherObservationResponse.java:21: error: cannot find symbol vp0_1 | @JsonIgnoreProperties(ignoreUnknown = true) vp0_1 |  ^ vp0_1 |  symbol: class JsonIgnoreProperties vp0_1 | 3 errors vp0_1 |  FAILED vp0_1 |  vp0_1 | FAILURE: Build failed with an exception. vp0_1 |  vp0_1 | * What went wrong: vp0_1 | Execution failed for task ':compileJava'. vp0_1 | > Compilation failed; see the compiler error output for details. vp0_1 | vp0_1 | * Try: vp0_1 | Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. vp0_1 |  vp0_1 | BUILD FAILED vp0_1 | vp0_1 | Total time: 8 mins 47.535 secs vp0_1 | vp0_1 | ********************

bfuentes
2017-01-04 17:03
humm

bfuentes
2017-01-04 17:03
i smells a missing dep declaration on gradle

bfuentes
2017-01-04 17:04
check that this lib is declared : com.fasterxml.jackson

bfuentes
2017-01-04 17:04
on the build.gradle

bercinho
2017-01-04 17:05
dependencies { compile 'io.grpc:grpc-all:0.13.2' compile 'commons-cli:commons-cli:1.3.1' compile 'org.hyperledger:shim-client:1.0' compile 'com.fasterxml.jackson.core:jackson-databind:2.8.3' compile 'org.apache.commons:commons-lang3:3.5' testCompile 'org.mockito:mockito-core:2.1.0' testCompile 'junit:junit:4.12' }

bfuentes
2017-01-04 17:05
compile 'com.fasterxml.jackson.core:jackson-databind:2.8.3'

bercinho
2017-01-04 17:05
its the copy of the Github one

bercinho
2017-01-04 17:05
no changes

bfuentes
2017-01-04 17:05
yep

bfuentes
2017-01-04 17:05
is on symbol @ ?

bfuentes
2017-01-04 17:06
[36mvp0_1 | @JsonIgnoreProperties(ignoreUnknown = true) vp0_1 |  ^

bfuentes
2017-01-04 17:06
weird

bfuentes
2017-01-04 17:06
vp0_1 | :compileJava/root/chaincode/src/main/java/com/ibm/WeatherObservationResponse.java:3: error: package com.fasterxml.jackson.annotation does not exist

bfuentes
2017-01-04 17:06
well is clear , no ?

bfuentes
2017-01-04 17:07
if you had this ?

bfuentes
2017-01-04 17:08
compile group: 'com.fasterxml.jackson.core', name: 'jackson-annotations', version: ‘2.8.3'

bfuentes
2017-01-04 17:08
*add

bfuentes
2017-01-04 17:08
give it a try

bercinho
2017-01-04 17:08
ok

bercinho
2017-01-04 17:08
let me check

bfuentes
2017-01-04 17:08
i have to go, i hope it will be ok

bfuentes
2017-01-04 17:09
;o)

bercinho
2017-01-04 17:10
ok, thanks

bercinho
2017-01-04 17:10
will let you know :slightly_smiling_face:

bercinho
2017-01-04 17:10
have a nice evening!

bercinho
2017-01-04 17:21
ERRO[0749] Handler for POST /containers/dev-vp1-eabe51054126401021124636e5439e48c82b677df501114333309db65426c47e35953c9204a3ab7c3661c468ced1ce086f6f470c9f8e5c47e5d5da5ef591360b/stop returned error: No such container: dev-vp1-eabe51054126401021124636e5439e48c82b677df501114333309db65426c47e35953c9204a3ab7c3661c468ced1ce086f6f470c9f8e5c47e5d5da5ef591360b ERRO[0749] Handler for POST /containers/dev-vp1-eabe51054126401021124636e5439e48c82b677df501114333309db65426c47e35953c9204a3ab7c3661c468ced1ce086f6f470c9f8e5c47e5d5da5ef591360b/kill returned error: Cannot kill container dev-vp1-

bercinho
2017-01-04 17:22
I still don´t get it, please let me know what should be the name of images and containers that are created for the Java Chaincode after the deploy transaction?

cbf
2017-01-04 18:57
so, fabric CI seems to be broken

yacovm
2017-01-04 19:17
Do you mean the chaincode tests or the I/O/routing issues ? @cbf

ry
2017-01-04 20:06
cbf: the slowdown due to routing should be fixed. The slowdown due to I/O is getting better very quickly

cbf
2017-01-04 22:13
@ry seems that the tests that @muralisr added for concurrent chaincode pushed it close to the 20 min limit

cbf
2017-01-04 22:14
I ran a few times locally and skipping the new test passes consistently where with it included it fails

cbf
2017-01-04 22:14
I'm going to submit a CS that skips the test unless a variable is set

ry
2017-01-04 22:15
ok

jojocheung
2017-01-05 06:53
has joined #fabric-dev

bercinho
2017-01-05 08:37
Hello Gents, many thanks for all the feedback, can you please explain the issue a bit so I have a better understanding? Thanks :slightly_smiling_face:

muralisr
2017-01-05 10:35
@cbf seems CI is working better today (at least 2 CI that timed out for me yesterday passed). The chaincode tests should take around 10-12 mins. Still too long but shouldn’t timeout on 20m. I’m going to refactor them into smaller test packages as a start (multichain_tests, concurrency_tests) and so on to at least reduce the time-per-UT

muralisr
2017-01-05 10:37
should also Skip some tests from the main (slight variations that don’t help a lot)

muralisr
2017-01-05 10:37
will try to take of this weekend

cbf
2017-01-05 13:03
ok, I will hold off then

jonathanlevi
2017-01-05 14:13
@greg_not_so: the `master` branch.

greg_not_so
2017-01-05 14:13
has joined #fabric-dev

greg_not_so
2017-01-05 14:22
@jonathanlevi i meant into my windows go directory

tuand
2017-01-05 14:35
@greg_not_so , use $GOPATH/src ... full path is $GOPATH/src/github.com/hyperledger/fabric

goms143
2017-01-05 14:39
has joined #fabric-dev

greg_not_so
2017-01-05 14:40
@tuand is this good for v1.0 or for v0.6 only?

tuand
2017-01-05 14:49
for both ... after that you're just switching btw github branches

conorfennell
2017-01-05 15:46
has joined #fabric-dev

ramykamel
2017-01-05 20:02
has joined #fabric-dev

eetti
2017-01-05 20:06
has joined #fabric-dev

mahoney
2017-01-05 20:08
Hi there. I'm having some issues related to the HFC install using NPM. Following the documentation, the command "npm install hfc", generates an error saying it doesn't support the version of node, and to update it. I've updated my node to the most recent version, and the error still remains. Is there a solution to this? (Aside from going back many versions in nodes.)?

jjjjibm
2017-01-05 20:19
fixtures_orderer_1 exited with code 137

jjjjibm
2017-01-05 20:19
Has anyone seen this message? What does it mean?

ghaskins
2017-01-05 21:22
@mahoney: try using node v6.x

ghaskins
2017-01-05 21:22
I think the message is deceiving

madhava
2017-01-06 02:24
@mahoney as per document the version should be minimum of npm version 2.11.3 and node.js version 0.12.7

goms143
2017-01-06 05:02
is it possible to change jim password in membersrvc.yaml file and make it as a new image ?

subaru365
2017-01-06 06:38
has joined #fabric-dev

bfuentes
2017-01-06 10:34
@goms143 you can do a new image if you have the source code, just run “make images” on the root of the project. Otherwise, you can register a new user using the sdk or HTTP API

goms143
2017-01-06 10:36
@bfuentes thanks but i have rebuilt my image using dockerfile and its working nw

mahoney
2017-01-06 13:06
Thank you for your quick responses!

ghaskins
2017-01-06 13:36
To whomever it was that was driving the ansible changes to baseimage: apologies, I cannot remember who it was nor can I find the CR to review.

ghaskins
2017-01-06 13:41
@jkilpatr Ah, google to the rescue: https://github.com/jkilpatr/fabric-baseimage-2.0

ghaskins
2017-01-06 13:42
(Sorry Justin, busy holidays)

fbenhamo
2017-01-06 19:22
has joined #fabric-dev

bartek
2017-01-08 13:44
has joined #fabric-dev

madhava
2017-01-08 16:41
Hi all, have deployed sample chain code02 and able to interact with it from CLI but would like to interact with chaincode through rest API using post ( invoke ) and get ( query ) methods, so how can i expose it can you share any references, am planning to expose services using node JS am referring https://github.com/hyperledger/fabric/blob/v0.6/examples/sdk/node/app.js but this js doesn't have any services exposed from it

newdev2524
2017-01-09 03:30
We're going to use production mode on v0.6, is there any standard hardware requirement or guideline to help estimate the performance? Thank you in advance for any answers.

arnaud
2017-01-09 16:14
@ghaskins hi and Happy New Year

ghaskins
2017-01-09 16:14
@arnaud likewise!

arnaud
2017-01-09 16:14
looking at the different repos I see that several new repos are missing the list of maintainers

arnaud
2017-01-09 16:15
I assume busybox, cop, and baseimage should have the same list as fabric

ghaskins
2017-01-09 16:15
@arnaud yes, i think the intention was that those inherit fabric, but you raise a valid point

arnaud
2017-01-09 16:15
of course busybox isn't even populated yet so that one is somewhat different

ghaskins
2017-01-09 16:16
if it will always track 1:1, should probably have a note in each that refers back to fabric.git

ghaskins
2017-01-09 16:16
and if its not expected to be 1:1, should have local list

arnaud
2017-01-09 16:16
yes, that's what I was thinking, we could just have a pointer

arnaud
2017-01-09 16:16
the one I don't know is sdk-node

ghaskins
2017-01-09 16:16
im guessing the potential is high for maintainers to be added to subprojects but not the top-level

ghaskins
2017-01-09 16:17
so maybe maintainers.md has a pointer that says "all the fabric maintainers + xyz"

arnaud
2017-01-09 16:17
ah, that's an idea

arnaud
2017-01-09 16:18
but I wonder whether this is accurately reflected in gerrit

ghaskins
2017-01-09 16:18
i think permissions wise, it is

ghaskins
2017-01-09 16:18
@ry ?

ghaskins
2017-01-09 16:19
my understanding is Ry has some kind of LDAP-like control and in there, there is an established relationship between fabric.git and the subprojects

ghaskins
2017-01-09 16:19
@arnaud btw: first CR against busybox.git https://gerrit.hyperledger.org/r/#/c/3761/

ghaskins
2017-01-09 16:19
so, hopefully populated soon

ghaskins
2017-01-09 16:19
(though not in the manner you are highlighting)

arnaud
2017-01-09 16:21
I'm looking at what's missing to exit fabric from incubation

arnaud
2017-01-09 16:22
one requirement is to have the list of maintainers documented

arnaud
2017-01-09 16:22
so we need to fill in the gap

arnaud
2017-01-09 16:22
I'm happy to submit patches but we need to agree on who should be listed for each repo :slightly_smiling_face:

arnaud
2017-01-09 16:22
unless everybody agrees with me deciding :wink:

ghaskins
2017-01-09 17:07
Im fine with that, would suggest starting with @ry's definitions in LDAP

ghaskins
2017-01-09 17:07
and we can discuss and reconcile the list

ry
2017-01-09 18:33
@ghaskins let me get a list together

ry
2017-01-09 18:38
@ghaskins @arnaud projects using the Fabric maintainer list (hyperledger-gerrit-fabric-committers): fabric fabric-baseimage fabric-busybox fabric-cop fabric-sdk-node

ry
2017-01-09 18:40
hyperledger-gerrit-fabric-api-committers: fabric-api hyperledger-gerrit-fabric-sdk-java-committers: fabric-sdk-java hyperledger-gerrit-fabric-sdk-py-committers: fabric-sdk-py hyperledger-gerrit-fabric-test-resources-committers: fabric-test-resources

ry
2017-01-09 18:40
if you need lists of the members of those LDAP groups I can provide those directly

ghaskins
2017-01-09 18:46
thanks @ry. On a related note, we can probably collapse fabric-test-resources into fabric

ghaskins
2017-01-09 18:46
i mean, maintainer list wise

ghaskins
2017-01-09 18:46
not the repo itself

ghaskins
2017-01-09 18:47
(if everyone agrees, of course)

ry
2017-01-09 18:51
ghaskins: right now it's a subset of fabric, probably due to inattention (if the lists were supposed to be the same)

ghaskins
2017-01-09 18:51
thats my guess

arnaud
2017-01-09 18:52
But I assume you have to list all the names anyway, right? There is no reference mechanism.

arnaud
2017-01-09 18:55
I mean for each project you have to have a flat list

arnaud
2017-01-09 18:55
You can't refer to another list

ry
2017-01-09 18:57
for the projects in the Fabric list, they literally use the same LDAP group. if that's what you're asking

arnaud
2017-01-09 18:58
Ah, all right then

arnaud
2017-01-09 18:58
That makes it easier actually :-)

ry
2017-01-09 18:58
one difficulty is people use different usernames and emails in gerrit than they use in maintainers.md. I'm not sure if people expect that to be private

arnaud
2017-01-09 18:58
That was what I was asking. Thanks

arnaud
2017-01-09 18:59
Yeah, that's a bit of a problem


arnaud
2017-01-09 18:59
Not so good for transparency

arnaud
2017-01-09 19:00
It was easier when all we had was github ids

ry
2017-01-09 19:00
since it also makes my life harder, I would like it not to be the case

arnaud
2017-01-09 19:00
But then we added slack ids

arnaud
2017-01-09 19:00
And then LF ids

arnaud
2017-01-09 19:00
And the list goes on

sukrit
2017-01-09 22:33
has joined #fabric-dev

rahulhegde
2017-01-10 01:10
has joined #fabric-dev

baohua
2017-01-10 06:14
suggest we at least keep some searchable info (gerrit id/email) at the maintainer.txt, this is helpful when people wanna find who is the developer of the projects, and especially to invite as reviewers.

egeek
2017-01-10 14:29
has joined #fabric-dev

divyank-sk
2017-01-10 14:59
why does fabric use year-old beta versions of grpc and protocol buffers?

yacovm
2017-01-10 14:59
Can you ask that in #fabric-dev-env please, @divyank-sk ?

arnaud
2017-01-10 15:03
@ghaskins hi Greg, I'm confused about the status of the chaintool project

arnaud
2017-01-10 15:04
why hasn't it been migrated to gerrit?

ghaskins
2017-01-10 15:15
@arnaud its on my "todo" but the blocking issue is I need to solve how I will serve release artifacts

ghaskins
2017-01-10 15:15
though, I probably can continue to use GH for this

ghaskins
2017-01-10 15:15

ghaskins
2017-01-10 15:16
and I upload the binary such that users/scripts may install the tool with a simple wget

ghaskins
2017-01-10 15:17
hmm, i just looked at the tags interface on -baseimage, doesnt seem I have permissions to add artifacts


ghaskins
2017-01-10 15:18
so, one solution would be: move to gerrit, set perms on GH mirror such that I can upload artifacts to GH/releases, done

ghaskins
2017-01-10 15:18
another solution would be to utilize some kind of repository that jenkins may populate (preferred)

ghaskins
2017-01-10 15:18
but the ambiguity here is precisely why the project is not yet in gerrit, heh

ghaskins
2017-01-10 15:19
@ry any thoughts on ^^^

ghaskins
2017-01-10 15:19
do we have the nexus server in a state where we might be able to push an arbitrary binary from jenkins and surface a download URL for users/scripts ?

ghaskins
2017-01-10 15:20
if so, thats probably the best option

ry
2017-01-10 15:20

ry
2017-01-10 15:21
there is a message missing there. Yes, nexus is there, and jenkins can push artifacts.

ghaskins
2017-01-10 15:22
im not clear on what logshipping is, but I get the gist of what you are saying

ry
2017-01-10 15:22
all of the build logs will be saved to nexus.

ry
2017-01-10 15:22
and that's working now. nexus is there and ready to use.

ghaskins
2017-01-10 15:23
assuming nobody objects, should we start to stage a gerrit-based fabric-chaintool and we can play around with GH import + jenkins integration?

ghaskins
2017-01-10 15:23
I can send another proposal email to give others a chance to chime in

ry
2017-01-10 15:23
probably a good idea

ghaskins
2017-01-10 15:24
ok

ry
2017-01-10 15:24
What hostname would you prefer for artifacts?

ry
2017-01-10 15:26
hmm I think logs is just an nginx rule to expand text files. it looks like you can link via urls like https://nexus.hyperledger.org/content/sites/logs/jobbuilder/vex-yul-hyp-jenkins-2/ ...

ghaskins
2017-01-10 15:36
ultimately it doesnt matter too much, i guess

ghaskins
2017-01-10 15:37
what I would care about is that at least for a given release (e.g. "v0.10.0" the URL is stable

ghaskins
2017-01-10 15:37
ideally, its consistent over time (such that only the version number changes)

ghaskins
2017-01-10 15:37
but even that is negotiable since the URL has to get updated at the consumer anyway


satheesh
2017-01-10 15:39
I am getting the above error when building peer from master. Am I missing something ?

ghaskins
2017-01-10 15:41
@satheesh not sure what the issue is: but when I have a similar question, I find it helpful to start by evaluating the history of the -merge job in question


ghaskins
2017-01-10 15:42
if the recent commits are blue, then its probably my environment/patch as opposed to broken mainline

ghaskins
2017-01-10 15:42
that doesnt mean there isnt a bug in mainline, of course, but its a data point

satheesh
2017-01-10 15:42
Thanks @ghaskins The merge jenkins jobs are blue

ghaskins
2017-01-10 15:43
in this case, I would guess there is indeed some kind of environment/local-patch issue though, as that seems too fundamental to have made it past the -merge job otherwise

ghaskins
2017-01-10 15:43
so, now the question is: what are you trying to do and how are you trying to do it?

ghaskins
2017-01-10 15:44
is this pure HEAD, in vagrant, with "make native" for instance?

ghaskins
2017-01-10 15:44
or are you doing something else?

satheesh
2017-01-10 15:45
I am building locally on a ubuntu, pure HEAD from origin/master

satheesh
2017-01-10 15:45
make all

ghaskins
2017-01-10 15:45
what sha?

satheesh
2017-01-10 15:46
`894febfca0337b81a3769919a5941f104d4f5960`

ghaskins
2017-01-10 15:46
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F3NT84UJD/-.xml and commented: run this please

ghaskins
2017-01-10 15:47
it looks like you are running v1.6, but I want to be sure

satheesh
2017-01-10 15:47
aah yes

satheesh
2017-01-10 15:47
`go version go1.6.2 linux/amd64`

ghaskins
2017-01-10 15:48
that is a problem: not sure its causing _this_ problem, but you will break somewhere along the way if you dont get 1.7.x

ghaskins
2017-01-10 15:48
i would suggest starting there

satheesh
2017-01-10 15:49
Got it, I will update my go version. Many thanks

ghaskins
2017-01-10 15:49
np

arnaud
2017-01-10 15:50
@ghaskins ok, I understand

ghaskins
2017-01-10 15:50
fyi, you can still build docker images as an alternative

ghaskins
2017-01-10 15:50
@satheesh "make docker", "make unit-test", etc, will still work

ghaskins
2017-01-10 15:50
just not all/native

ghaskins
2017-01-10 15:51
@cbf wonder if we should add a check to the build

ghaskins
2017-01-10 15:51
based on "go version", i mean

jonathanlevi
2017-01-10 16:02
@ghaskins: I think so, yes.

jonathanlevi
2017-01-10 16:03
We should have a config entry stating the required go version. (even major rev should do).

jonathanlevi
2017-01-10 16:03
Especially as/while we work with pre-built images… mixing them/version would be a nightmare.

arnaud
2017-01-10 16:04
I agree that would make sense if we depend on a specific version

jonathanlevi
2017-01-10 16:04
Yup & if someone wants to build EVERYTHING from scratch, say with go1.8beta - they should be able to do so - but they need to explicitly change these configs.

ghaskins
2017-01-10 16:04
to my knowledge, as it stands we require 1.7.x or greater

jonathanlevi
2017-01-10 16:04
(so that we know they know)

jonathanlevi
2017-01-10 16:05
Yup, 1.7.x

jonathanlevi
2017-01-10 16:05
1.7.3 in most cases (I work with 1.7.4 and it’s fine too…)

jonathanlevi
2017-01-10 16:05
Not that 1.7.4 is a better “size” or anything :wink:

ghaskins
2017-01-10 16:05
do we need 1.7.3?

jonathanlevi
2017-01-10 16:05
I think 1.7.x is fine.

ghaskins
2017-01-10 16:05
or is 1.7.0 ok too?

ghaskins
2017-01-10 16:05
ok

ghaskins
2017-01-10 16:06
ill see if I can come up with an unobtrusive check for 1.7.x or greater

ghaskins
2017-01-10 16:06
if for only to throw a nice clean msg rather than some esoteric fail

jonathanlevi
2017-01-10 16:07
“The sooner we fail - the better” :wink:

arnaud
2017-01-10 16:07
:slightly_smiling_face:

ry
2017-01-10 16:09
it will make the "why doesn't this work?" emails easier to puzzle out, for sure

jonathanlevi
2017-01-10 16:19
Yup - to clarify my “joke” above - the main problem is that these “mixes” are much harder to debug/report/detect, as they may occur at a much later step.

madhava
2017-01-10 16:27
hi all, when i try to deploy sample chain code02 from inside docker peer container, am getting "cannot connect to Docker endpoint" error peer | 16:20:57.582 [container] lockContainer -> DEBU 185f got container (dev-vp0-ee5b24a1f17c356dd5f6e37307922e39ddba12e5d2e203ed93401d7d05eb0dd194fb9070549c5dc31eb63f4e654dbd5a1d86cbb30c48e3ab1812590cd0f78539) lock peer | 16:20:57.583 [dockercontroller] deployImage -> ERRO 1860 Error building images: cannot connect to Docker endpoint peer | 16:20:57.583 [dockercontroller] deployImage -> ERRO 1861 Image Output: peer | ******************** peer |

madhava
2017-01-10 16:32

madhava
2017-01-10 16:33
this is the complete log from peer, could you please help on the error

silliman
2017-01-10 19:15
@madhava are you running on v0.6 or v1.0 and, if you were using Docker compose to start your containers, could you paste in the contents of your Docker compose yaml file? Likely causes are that Docker daemon is not running on your host or that the property in core.yaml on the Peer (which can be overridden by the CORE_VM_ENDPOINT environment variable) is not properly configured so that you can get to your Docker daemon from the container

wjq
2017-01-11 06:17
Hello. Does anyone know in fabric 0.6, how tcert and ecert are related? for example, how the auditors know one tcert is owned by the ecert?

ashutoshkumar
2017-01-11 12:58
@wjq : In TCert , there is an extension called enrollment id which is Subject name of ECERT.

madhava
2017-01-11 13:35
@silliman, i tried with Docker images with Docker Compose and its working fine, thank you for your response

madhava
2017-01-11 13:59
Hi All, am running fabric with Docker containers also i deployed sample chain code by following below link


madhava
2017-01-11 14:02
through CLI as well as with postman am able to invoke and query chain code but would like to use HFC to interact with chain code and for this am referring the NodeJS SDK from example

madhava
2017-01-11 14:02

madhava
2017-01-11 14:03
would like to know how the values gets assigned to below variables var PEER_ADDRESS = process.env.CORE_PEER_ADDRESS; var MEMBERSRVC_ADDRESS = process.env.MEMBERSRVC_ADDRESS;


madhava
2017-01-11 14:25
this is current .yml file

wjq
2017-01-11 15:19
@wjq uploaded a file: https://hyperledgerproject.slack.com/files/wjq/F3PDVUNKT/how_to_set_tls_enabled.yaml and commented: Hello, in fabric 0.6, I tried to use with tls enabled. But I get " connection error: desc = "transport: x509: certificate signed by unknown authority"; Reconnecting to {"localhost:7054" <nil>" .Can anyone help me? how should I set the tls config?

jyellick
2017-01-11 19:35
https://jira.hyperledger.org/browse/FAB-1608 <- this is a cleanup related item around our golang package structure, I've started on it, but as I realize how wide reaching this may be, wanted to try to publicize it a bit more in case anyone has some feedback or disagrees. @muralisr @binhn @garisingh @kostas @sanchezl @tuand @adc @aso @elli @yacovm @dave.enyeart (This list tries to hit some of the bigger category maintainers but is likely incomplete so please publicize to anyone you think might care).

muralisr
2017-01-11 19:40
@jyellick this is a good thing to start… but non trivial for sure as you point out

muralisr
2017-01-11 19:43
we have layers at a hight level something like util -> ledger -> gossip -> [committer, endorser] -> peer

muralisr
2017-01-11 19:43
as long as imports flow from top to bottom that would at least be “clean” in one sense

muralisr
2017-01-11 19:44
sometimes things like having to call system chaincode in the opposite direction gets in the way

yacovm
2017-01-11 19:44
util?

muralisr
2017-01-11 19:45
proto/utils

yacovm
2017-01-11 19:45
proto/utils references the ledger? how?

yacovm
2017-01-11 19:45
singleton?

muralisr
2017-01-11 19:45
-> is not “referencing” ….

yacovm
2017-01-11 19:45
oh

muralisr
2017-01-11 19:46
let me redraw a bit

muralisr
2017-01-11 19:46
meant to indicate “stack"

yacovm
2017-01-11 19:46
so it's the other way around?

muralisr
2017-01-11 19:46
util / ledger / gossip / [committer, endorser] / peer

muralisr
2017-01-11 19:46
well

kostas
2017-01-11 19:46
I left a comment along these lines on the issue.

muralisr
2017-01-11 19:46
except peer can call both ledger and util

kostas
2017-01-11 19:47
The rules on `protos` means that the `utils` package will need to be moved out of it, which is the right move semantically IMO.

muralisr
2017-01-11 19:47
right

kostas
2017-01-11 19:47
That `utils` package becoming a kitchen-sink is already starting to cause a few import cycle issues, e.g. https://gerrit.hyperledger.org/r/#/c/3869/1/orderer/common/filter/filter_test.go@123

muralisr
2017-01-11 19:47
which is why I started with “util"

muralisr
2017-01-11 19:47
but there are two issues IMO

muralisr
2017-01-11 19:49
1) layering (which is what I tried to indicate above) and (2) using interfaces, factories and providers to really bring out the layering and interactions

muralisr
2017-01-11 19:49
not sure how much we want to go after … sounds to me (1) is what we are starting off with ?

muralisr
2017-01-11 20:03
I think just making sure we take care of minimizing upstack imports in the layers will be a great first step

ghaskins
2017-01-11 23:47
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F3PN2G9A5/-.sh and commented: Anyone have a working example of a devmode deployment on master? I get this error.

ghaskins
2017-01-12 03:30
I got past this problem by using "CORE_CHAINCODE_ID_NAME=mycc:0/**TEST_CHAINID**"

ghaskins
2017-01-12 03:31
however, I dont think that is the only problem, as I cant invoke transactions against this instance

ghaskins
2017-01-12 03:31
(I can deploy, but I cant invoke)

ghaskins
2017-01-12 03:31
something seems fundamentally broken (it could very well be my understanding ;)

ghaskins
2017-01-12 03:31
@muralisr are you invoking transactions on a regular basis against HEAD?

muralisr
2017-01-12 03:33
pretty regularly @ghaskins

muralisr
2017-01-12 03:33
a few hours back on latest

ghaskins
2017-01-12 03:33
hmm, netmode or devmode?

muralisr
2017-01-12 03:33
but I always use cli

muralisr
2017-01-12 03:33
both

muralisr
2017-01-12 03:33
are you doing devmode ?

ghaskins
2017-01-12 03:33
yeah

muralisr
2017-01-12 03:34
from cli ?

ghaskins
2017-01-12 03:34
i dont understand where the mycc:0/**TEST_CHAINID** stuff is coming from

ghaskins
2017-01-12 03:34
both, well, mostly SDK but I sanity checked on CLI once

ghaskins
2017-01-12 03:34
I saw same behavior from both SDK and CLI

ghaskins
2017-01-12 03:35
that is, sending "chaincodeId: mycc" maps to a request with mycc:0/**TEST_CHAINID** on the peer

ghaskins
2017-01-12 03:35
so, if I register my devmode chaincode with that FQN, it works (for deploy, but fails invoke)

muralisr
2017-01-12 03:35
the system is initialzed for **TEST_CHAINID**

muralisr
2017-01-12 03:35
till we get multichannel stuff working

ghaskins
2017-01-12 03:36
so, when you do devmode+cli, what are you using as a chaincodeid ?

muralisr
2017-01-12 03:36
yes

muralisr
2017-01-12 03:36
do you want to do a quick hangout

muralisr
2017-01-12 03:36
?

muralisr
2017-01-12 03:36
i can show you what I do

ghaskins
2017-01-12 03:36
sure

ghaskins
2017-01-12 03:36
ill fire up and PM you

muralisr
2017-01-12 03:36
ok

muralisr
2017-01-12 03:37
that works too

ghaskins
2017-01-12 16:55
@cbf pushed a v7 for 3761 which optimizes the layers

rachweb2
2017-01-12 17:22
has joined #fabric-dev

cbf
2017-01-12 18:12
still something weird with the test target

ghaskins
2017-01-12 18:15
in the busybox.git/Makefile?

ghaskins
2017-01-12 18:15
or in the JJB execution of it?

ghaskins
2017-01-12 18:16
I havent looked too deeply at the Jenkins/JJB stuff since its still WIP, but the local target seems to work reliably for me

cbf
2017-01-12 18:16
I just ran locally and everything works

cbf
2017-01-12 18:16
though I got a clock skew message

cbf
2017-01-12 18:17
cbf$ make test docker run -i --rm -v /Users/cbf/dev/fabric-busybox:/mnt -w /mnt hyperledger/fabric-baseimage:x86_64-0.2.2 make -f Makefile.busybox install BINDIR=build BUSYBOX_VERSION=1.25.1 make: Warning: File 'Makefile.busybox' has modification time 1593 s in the future make -C build/.1.25.1 -l 2.5 -j all LDFLAGS=-static make[1]: Entering directory '/mnt/build/.1.25.1' make[1]: Warning: File '.kernelrelease' has modification time 1612 s in the future make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory '/mnt/build/.1.25.1' make: warning: Clock skew detected. Your build may be incomplete. docker run hyperledger/fabric-busybox:x86_64-1.25.1-1-snapshot-e950ee5 echo "It works" It works

ghaskins
2017-01-12 18:17
thats interesting

cbf
2017-01-12 18:17
who wrote the jjb stuff? I still don't get that;-)

ghaskins
2017-01-12 18:17
heh, i dont know, i didnt look but I suspect Ramesh

ghaskins
2017-01-12 18:18
oh you mean the framework?

ghaskins
2017-01-12 18:18
no idea

cbf
2017-01-12 18:18
ok, we'll I will

cbf
2017-01-12 18:18
+2 and +1 verify

ghaskins
2017-01-12 18:18
ive seen the clockskew stuff typically in the context of vagrant->volumemount->host

ghaskins
2017-01-12 18:18
but never on these native builds

ghaskins
2017-01-12 18:19
or at least, not that I have noticed

arnaud
2017-01-12 18:32
I saw a clock skew warning too yesterday although I can't remember what exactly I was doing :-(

arnaud
2017-01-12 21:56
@ghaskins does your change of employer make any difference as to your likelihood of coming to the hackfests?

ghaskins
2017-01-12 22:14
tbd

ry
2017-01-12 23:00
@arnaud: I thought we were going to IBM San Jose this time?

ry
2017-01-12 23:01
Or was it cbf that expressed that desire?

cbf
2017-01-12 23:23
no, the group voted in favor of SF over SJ

ry
2017-01-12 23:26
Oh ok. I missed that

bercinho
2017-01-13 10:27
Dear All, does anyone know why I may not have Internet access within the Hyperledger docker containers connecting to the same overlay network?

ghaskins
2017-01-13 13:23
@bercinho I just discovered a problem late last night that might be related

ghaskins
2017-01-13 13:24
this isnt conclusive, but I think the general problem is that DNS lookups do not work

ghaskins
2017-01-13 13:24
preliminary analysis is its related to how we are building the static binaries (peer/orderer/busybox) and a bug/limitation in glibc for static linking

ghaskins
2017-01-13 13:25
stay tuned

bercinho
2017-01-13 14:27
Hi Greg, many thanks for the update! looking forwad hearing back from you.

tzipih
2017-01-13 14:39
Does anyone know when should we expect support for multiple endorser peers?Right now we are working with the skeletal example (in https://jira.hyperledger.org/secure/attachment/10242/simple_test_with_skeletal_peer.md)

tzipih
2017-01-13 14:39
but we need more than one endorser fo the things we want to do

ghaskins
2017-01-13 15:17
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F3QHG3GF3/-.ml and commented: @cbf, i understand more about how it works now

ghaskins
2017-01-13 15:18
the busybox binary was statically linked in the same way we do it for real, but it was able to resolve the address when running in plain ubuntu because I think the libc is doing a dlopen

ghaskins
2017-01-13 15:18
(and the files were present


garisingh
2017-01-14 23:52
@ghaskins - my guess would also be that you'd likely only see this issue when running on OSX (and possibly Windows - although I believe that the VM used on Windows has the correct libraries)

garisingh
2017-01-14 23:54
is there any reason for us not to use the "official" busybox images? Or minimally we could just copy their build for say the uclibc version? (I guess we do have to build for Z and P)


ghaskins
2017-01-15 01:06
@garisingh: actually the problem is build environment neutral. We compile both busybox and the golang code in our baseimage container

ghaskins
2017-01-15 01:07
The glibc in question is therefore picked up in our Debian/Ubuntu ecosystem

ghaskins
2017-01-15 01:09
I explain the ratioale for not using the official busybox here: https://github.com/hyperledger/fabric/commit/b61723f9ddcc91cafd4f3a8c3634bd8d32388b32

ghaskins
2017-01-15 01:10
One complication here is the multiarch stuff as you noted. Another is that it's not only busybox that is broken

ghaskins
2017-01-15 01:10
Our golang apps pick up the bad dns functions too

ghaskins
2017-01-15 01:11
There are numerous ways to solve this but most of them are probably untenable from either a support and/or licensing perspective

ghaskins
2017-01-15 01:12
I think I have a workable solution being tested right now though

ghaskins
2017-01-15 01:12
I'm mobile ATM but I'll provide details later

ghaskins
2017-01-15 01:13
We'll need to take a small hit on size for the short term (e.g. Peer goes from 25M to 155M (uncompressed)

ghaskins
2017-01-15 01:14
I think I can reign this in again (at least on X) in the midterm

ghaskins
2017-01-15 01:14
But right now focus is on correctness

ghaskins
2017-01-15 01:17
Honestly though, the size thing is probably less important than we make it out. The peer still needs ccenv or something like it in order to function, no matter how clever I can get here

ghaskins
2017-01-15 01:18
I still think a minor argument can be made that smaller is still better, so I am not giving up on this.

ghaskins
2017-01-15 01:18
Just a detour ;)

ingcr3at1on
2017-01-15 18:10
has joined #fabric-dev

nickmelis
2017-01-16 16:42
has joined #fabric-dev

nickmelis
2017-01-16 16:43
has anyone here worked on the chaincode implementation of table? I need to understand how the getRows function works (search by partial key) and why it hasn’t been ported in Java

ghaskins
2017-01-16 17:08
@nickmelis not sure what you are targeting, but FYI: https://gerrit.hyperledger.org/r/#/c/3649/

ghaskins
2017-01-16 17:09
FWIW, my former teammates at LSEG used the Table API extensively in v0.6 and earlier: @bensor might have more details

bensor
2017-01-16 17:09
has joined #fabric-dev

nickmelis
2017-01-16 17:11
@ghaskins here’s the thing, I’m trying to store a data structure with four different fields, three of which are keys

nickmelis
2017-01-16 17:11
something that doesn’t fit in a map <string, string>

ghaskins
2017-01-16 17:12
I understand, my understanding is the plan is to replace Table API with something couchdb-ish

nickmelis
2017-01-16 17:12
and I’ve played a bit with the Table API in Java, and then realised there’s no getRows() function to select results which match only one of the three fields in the key

ghaskins
2017-01-16 17:13
(or perhaps that interface is already available, not sure

ghaskins
2017-01-16 17:13
i am not an expert in this area, mostly wanted you to be aware that it was being yanked

nickmelis
2017-01-16 17:13
getRows is available in Go, although I don’t really understand how it works, and if it relies on the underlying state map

ghaskins
2017-01-16 17:14
well, not after CR 3649 goes in :wink:

ghaskins
2017-01-16 17:14
then Go and Java will be equally deficient :wink:

nickmelis
2017-01-16 17:14
right, so Table API are being removed. Is there anything to query the state map by partial key then?

ghaskins
2017-01-16 17:14
IIUC

ghaskins
2017-01-16 17:15
Like I said, my understanding is there is some couchdb/json-based QL going in

ghaskins
2017-01-16 17:15
I am not sure what the status is

nickmelis
2017-01-16 17:15
we’re talking about > v0.6 though, right?

ghaskins
2017-01-16 17:15
I can say that the Table API was pretty weak...it was hard to build real applications with it

ghaskins
2017-01-16 17:15
yes, in master

ghaskins
2017-01-16 17:15
for v0.6, Table API is in place (at least in Go shim)

nickmelis
2017-01-16 17:16
is there anyone who worked on Table API in the first place here?

ghaskins
2017-01-16 17:16
@muralisr might know

nickmelis
2017-01-16 17:17
thanks :slightly_smiling_face:

weeds
2017-01-16 21:44
@nickmelis go to the fabric-ledger-dev channel and ask Dave Enyeart

weeds
2017-01-16 21:45
or manishsethi

tsluthra
2017-01-17 15:54
has joined #fabric-dev

mohanv
2017-01-17 18:43
@nickmelis .. Here is an example -- I use it with a custom table in 0.6

mohanv
2017-01-17 18:45
rowChannel, err := stub.GetRows(tableName, columns) if err != nil { return nil, fmt.Errorf("GetList operation failed. %s", err) } var rows []shim.Row for { select { case row, ok := <-rowChannel: if !ok { rowChannel = nil } else { rows = append(rows, row) //If required enable for debugging //fmt.Println(row) } } if rowChannel == nil { break } } fmt.Println("Number of Keys retrieved : ", nKeys) fmt.Println("Number of rows retrieved : ", len(rows)) return rows, nil }


mohanv
2017-01-17 19:09
4

kzhang
2017-01-18 19:43
has joined #fabric-dev

choas
2017-01-18 20:24
has joined #fabric-dev

tzipih
2017-01-19 12:57
Hi can anyone suggest in which place in the code do we need to look to open multiple endorsers? We are trying to implement an example using such a scenario. Thx.

cbf
2017-01-19 13:40
@muralisr ^^

muralisr
2017-01-19 13:44
@tzipih that code for a single command/api to send to multiple endorsers is not there currently… the two high level interfaces for sending proposals to endorsers are the CLI and the SDK. They can be used - currently - to send to 1 endorser.

muralisr
2017-01-19 13:48
Please check on fabric-sdk-node or fabric-sdk-node-dev on plans for allowing a proposal to be sent to multiple endorsers

muralisr
2017-01-19 13:50
what you *can* do today which is not satisfactory by any means … is to use the CLI `CORE_PEER_ADDRESS=<endorserip>:<endorserport> peer chaincode query …` multiple times

muralisr
2017-01-19 13:50
the query command will NOT send the proposal response to the orderer

muralisr
2017-01-19 13:51
this way you can send as many requests you want to N-1 endorsers

muralisr
2017-01-19 13:52
and on the last one, do an invoke as `CORE_PEER_ADDRESS=<endorserip>:<endorserport> peer chaincode invoke …`

muralisr
2017-01-19 13:52
like I said - not satisfactory :slightly_smiling_face:

muralisr
2017-01-19 13:53
it is not hard to add support for multiple endorsers to the CLI (hopefully will be done soon)… if you want take a stab at it, I can help. Do let me know

muralisr
2017-01-19 13:54
but if you want to use the SDK to do the above please check on the fabric-sdk-dev or fabric-sdk-node-dev channels

dknochen
2017-01-19 15:39
has joined #fabric-dev

harrisob
2017-01-19 15:56
fabric-sdk-node supports multiple endorsers

tzipih
2017-01-19 16:11
Thank you yes, I do want to implement and use this. I will check the suggested channels.

kamo
2017-01-19 16:21
Is it possible to run all examples of the master branch(authorizable_counter, asset-management, etc. ) with v1.0 ? Or do I have to modify the chaincode?

muralisr
2017-01-19 16:28
@harrisob thanks for the correction… @tzipih so you should be able to use the SDK to send a proposal to multiple endorsers

tzipih
2017-01-19 16:59
@muralisr Thanks. I was wondering whether it is possible to run multiple endorser peers natively (without docker containers).

tzipih
2017-01-19 17:00
I guess I just need to give them different ids and different ports. Or do I need to do something else?

muralisr
2017-01-19 17:00
@tzipih I am not sure (I can imagine how it can be done)..

muralisr
2017-01-19 17:01
well the ledger directory has to be different as well, for one thing

muralisr
2017-01-19 17:01
but the recommendation would be to use docker

muralisr
2017-01-19 17:02
peer’s being on the same os env would be a very unusual pattern

tzipih
2017-01-19 17:03
Ok. I'll use docker.

tzipih
2017-01-19 17:03
Do you have an example with docker containers with v1.0

tzipih
2017-01-19 17:04
Up to now, I only used the skeletal example with one native peer and orderer

muralisr
2017-01-19 17:04
yes… there are workable docker-compose files under bddtests

tzipih
2017-01-19 17:05
Ok. Thanks. I'll look at it.

muralisr
2017-01-19 17:05
fabric/bddtests/docker-compose-next-4.yml would be a good start but would defer to @jeffgarratt if there’s a better one

jeffgarratt
2017-01-19 17:06
@tzipih @muralisr correct, that is the one

jeffgarratt
2017-01-19 17:06
over the next couple of days there should be a good example of actual usage

tzipih
2017-01-19 17:20
@jeffgarratt Thanks. I can run it using docker-compose. But then, what's the best way to communicate to the peers / deploy a chaincode / invoke a chaincode? It seems that all the ports of the peers are closed from the outside of docker.

jeffgarratt
2017-01-19 17:20
that part is coming :slightly_smiling_face:

jeffgarratt
2017-01-19 17:21
every port is actually available

jeffgarratt
2017-01-19 17:21
just not exposed

jeffgarratt
2017-01-19 17:21
but you can connect to them

jeffgarratt
2017-01-19 17:21
we are working on behave tests to demonstrate the entire boostrap of the network

jeffgarratt
2017-01-19 17:22
to include the final create/join channel with subsequent TXs (deploy, invoke, etc.)

jeffgarratt
2017-01-19 17:23
the purpose of the boostrap feature is to demonstrate the full configuration and usage of the network wrt to peers and orderers (and MSPs)

jeffgarratt
2017-01-19 17:23
if you like, can add you to the Jira isse to track


tzipih
2017-01-19 17:28
Thanks.

tzipih
2017-01-19 17:28
Is there a simple way to expose them to peer deploy?

tzipih
2017-01-19 17:29
I tried adding ports 7051 to vp0 in the docker-compose file

cbf
2017-01-19 17:37
ICYMI - we renamed the fabric-cop component to fabric-ca by popular demand;-) any changesets in flight may have merge conflicts best to cherrypick the changeset and apply to a clone of the new repo and then push again


cbf
2017-01-19 17:39
per @ry you don't need to clone the new repo, you can simply change your git remote

jeffgarratt
2017-01-19 17:40
@tzipih you should be able to use docker exec -it <container_id> peer chaincode .... commands

jeffgarratt
2017-01-19 17:40
use the peerX node (your choice)

jeffgarratt
2017-01-19 17:41
and the SDK should also work fine

ghaskins
2017-01-19 17:47
@tzipih not sure this is exactly what you were looking for: but check out fabric.git/test/docker-compose.yml

tzipih
2017-01-19 17:50
@jeffgarratt Thanks. I tried ```docker exec -it bddtests_vp0_1 peer chaincode deploy -n mycc -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}'1``` but I got ```2017-01-19 17:49:08.487 UTC [msp] GetDefaultSigningIdentity -> INFO 01c Obtaining default signing identity panic: runtime error: index out of range```

jeffgarratt
2017-01-19 17:51
@tzipih @muralisr may be able to quickly answer that one

jeffgarratt
2017-01-19 17:51
and you have an extra 1 at end it appears

jeffgarratt
2017-01-19 17:51
not sure that is issue though

tzipih
2017-01-19 17:54
No, that's just an issue when copy/pasting...

jeffgarratt
2017-01-19 17:54
k, :wink:

jeffgarratt
2017-01-19 17:55
@muralisr may need to step in to explain if params are complete

tzipih
2017-01-19 17:55
@ghaskins Thanks. Unfortunately, this one has only one peer.

ghaskins
2017-01-19 17:55
i meant it as an example of port surfacing

tzipih
2017-01-19 17:56
Yes indeed.

tzipih
2017-01-19 17:56
Thanks. Apparently, we need to expose also 7050

tzipih
2017-01-19 17:56
otherwise, we have `Error: Error getting broadcast client: Error connecting to 0.0.0.0:7050 due to grpc: timed out when dialing` when peer chaincode deploy `

ghaskins
2017-01-19 17:57
via the orderer, though

ghaskins
2017-01-19 17:57
not the peer

tzipih
2017-01-19 17:58
OK, but after adding ports: 7050:7050 to the orderer

tzipih
2017-01-19 17:58
This example with one peer seemed to work.

tzipih
2017-01-19 18:00
when running `peer chaincode ...` outside `docker`

tzipih
2017-01-19 18:00
So we'll try to add more peers after our lunch.

ghaskins
2017-01-19 18:02

ghaskins
2017-01-19 18:02
it may impact the ability for the peer container to find the orderer, etc

ghaskins
2017-01-19 18:02
i have it fixed locally, fwiw

ghaskins
2017-01-19 18:03
would be willing to share

jjjjibm
2017-01-19 18:03
Test post (we're working on the format): Functional Integration Test (FIT): Result=Passed Commit level: Peer: 22ec03f COP: 9c6c125 node-sdk: 7eef633

bmos299
2017-01-19 19:08
The CI team (Ramesh) has created an end-to-end Jenkins Job called FIT and is currently run in the Jenkins sandbox. FIT stands for Functional Integration Test. The test is currently based on node sdk end-to-end tests. End-to-end implies the need for all architectural components and the corresponding docker images built from the corresponding repository for the: orderer, ca (formerly known as cop), and endorser. The FIT test will grow and tests will be added to the Jenkins Job. In particular, we will be adding the creation of channels/chains in the near future. The results from the Job will be posted to this channel, with pass/fail status, a link to the job, the docker-compose used, and logs. If the job fails a JIRA issue will be opened manually. If the job passes the associated docker images will be pushed and tagged to org: rameshthoomu. The publishing of images to Ramesh's public docker repository is a short-term solution. Links to the tagged images will be in the slack message. The Job will be run daily, at midnight, and primed with a run in the next hour.

ramesh
2017-01-19 19:15
added an integration to this channel: https://hyperledgerproject.slack.com/services/B3TQKS3K5

ramesh
2017-01-19 20:33

tzipih
2017-01-19 20:55
@muralisr @jeffgarratt when run outside docker, `peer chaincode deploy ...` failed and the peer vp0 whose ports were mapped to the machine logged ```vp0_1 | 2017-01-19 20:43:10.501 UTC [dockercontroller] deployImage -> ERRO 19b Error building images: cannot connect to Docker endpoint vp0_1 | 2017-01-19 20:43:10.501 UTC [dockercontroller] deployImage -> ERRO 19c Image Output: vp0_1 | ******************** vp0_1 | vp0_1 | ******************** ```

tzipih
2017-01-19 20:58
But we managed to fix it by setting `CORE_VM_ENDPOINT` to `unix:///var/run/docker.sock` instead of `http://172.17.0.1:2375` in `bddtests/compose-defaults.yml` and adding ```volumes: - /var/run/docker.sock:/var/run/docker.sock ``` to this file too inside `vp`.

tzipih
2017-01-19 20:59
This seemed to work.

muralisr
2017-01-19 21:05
@tzipih right… there are variations depending on how your docker env is setup

tzipih
2017-01-19 21:10
@muralisr thanks for your help, appreciate it!

cbf
2017-01-19 21:19
this is great progress @bmos299 and @ramesh

cbf
2017-01-19 21:19
but could we have the jenkins slack integration write to #fabric-ci-status?

ramesh
2017-01-19 21:20
yes we have

cbf
2017-01-19 21:20
oh good

cbf
2017-01-19 21:20
I saw the bot message above and was worried about spamming this channel

ramesh
2017-01-19 21:21
ok next build result will publish to #fabric-ci-status

binhn
2017-01-20 14:44
@cbf @ramesh I am ok with #fabric-ci-status but developers rarely look there unless there’s a ci problem; not sure about none-fabric developers, but i guess they would come here more often

cbf
2017-01-20 14:45
@binhn exactly - my concern is that the bot messages be perceived as spam and people will be annoyed at their conversations being hijacked with interspersed bot spam

cbf
2017-01-20 14:46
IMO, they only need to go to ci-status if there's a problem

cbf
2017-01-20 14:47
if we can post ONLY failed builds here, and then just a reference to the build's output (not a large post) that might be okay

binhn
2017-01-20 14:48
ok, agreed

davidpeyronnin
2017-01-20 15:54
has joined #fabric-dev

john.d.sheehan
2017-01-20 16:24
has joined #fabric-dev

baohua
2017-01-21 23:25
Would like to throw an old item: https://jira.hyperledger.org/browse/FAB-1412. Currently, `make peer` will first build lots of dependencies (e.g., those run-time docker images) implicitly and then compile the peer binary (like a `make peer-all`). I guess it would be helpful if we can decouple those two steps by providing some method to enable just compiling the binary (save time and efforts), as the `make peer`‘s doc says: `builds a native fabric peer binary`. Would like to hear more comments, thanks!:slightly_smiling_face:

ghaskins
2017-01-21 23:36
@baohua the coupling was intentional since the peer cannot really run without the prerequisites. Disabling that can cause its own set of problems that I would classify as worse than developer inconvenience, especially since (baring bugs) it should employ build caching/optimization

ghaskins
2017-01-21 23:36
I think FAB-1412 is likely just a bug that needs addressing, but I would treat FAB-1412 as different from your decoupling request

garisingh
2017-01-21 23:38
plus you can always build the peer binary directly with `go build`

garisingh
2017-01-21 23:38
that's what I do :wink:

garisingh
2017-01-21 23:38
I actually build the orderer that was as well

ghaskins
2017-01-21 23:49
I would discourage that in general as you wont pick up all of the same flags

ghaskins
2017-01-21 23:49
most notably, the metadata.Version wouldnt be provided

ghaskins
2017-01-21 23:49
perhaps we need a "training-wheels off" mode for the build, then

garisingh
2017-01-21 23:50
well I'm just doing it for quick local tests - not for distributing binaries

ghaskins
2017-01-21 23:50
understood, I actually meant that more as an example

ghaskins
2017-01-21 23:50
today, its not too harmful, but tomorrow it could be

garisingh
2017-01-21 23:50
not sure what @baohua really wants to do

ghaskins
2017-01-21 23:51
today the only implication is you dont get the metadata baked in, but that could change without notice

ghaskins
2017-01-21 23:51
(actually, you also get slightly different optimization levels

baohua
2017-01-22 06:08
@garisingh @ghaskins yeap, understand that we need the dependencies to run the peer. Building such is not that stable with downloading stuffs from various sources. Maybe we can add some `make binary` to simply build out those binaries with `go build`.

ghaskins
2017-01-22 14:12
well, thats just a bug that should be fixed

ghaskins
2017-01-22 14:12
if the build was stopped for whatever reason, it should be smart enough to pick up where it left off

simers
2017-01-22 15:05
has joined #fabric-dev

weeds
2017-01-23 14:32
A few people are meeting to talk about the status of the Master code base. I am slacking the information as a result- this is real time discussion

weeds
2017-01-23 14:35
There are multiple lists on the board-- these are all the stuff we want to walk through and determine where we are specifically-- TLS, validation message and TX, replay attacks, replication MSPs for gossip, anchor peers, channel leaders, HSM (key generation), chaincode return object, chaincode endorsement policy, revisit events, chaincode life-cycle (deploy/init upgrade,.. and policy), ERror handling, bootstrap with pre-defined channels, custom TX, CLI accepts multiple peers, application crypto library, system Chaincode refactor (location) and Chaincode calling chaincode

weeds
2017-01-23 14:36
For SDK- (node.js, and Java)- Java only : create "official"branch, events support (example: rejection in blockchain), chain join ( creation basically done), REST wrapper, anything left in MSP, Java Chaincode, TCERt private key derivation, query on ledger

weeds
2017-01-23 14:38
For SDK- add RSA , escc, vscc

weeds
2017-01-23 14:40
For Docs- high level overview- ferris; technical overview- Josh; remove version 0.6 material; docker compose- 3 configs; ordering configs, CA configs- Keith ; APIs- Jz, SDK- JZ, policies- Murali; channels- murali

weeds
2017-01-23 14:40
For Docs- end to end Barry/Ramesh

weeds
2017-01-23 14:42
For Fabric - CA: Docs- API doc /swagger; readme; read the docs,... CLI simplification; TCERt- BCCSP integration/. option 2 (HSM friendly) support; HSM support- BCCSP or lets ecnrypt PrSCH; BCCSP for auth. header; Intermediate CA support? ; Test

weeds
2017-01-23 14:42
For BDD- RSA, P384, Deploy CC, Mutlichannel

weeds
2017-01-23 14:42
That is what is currently on the board...

weeds
2017-01-23 14:43
Binh- let's quickly review this list and anything else we can add on, but these are the items that we want to target for alpha for the end of this month

weeds
2017-01-23 14:43
(items are being added that I will try to add here)

weeds
2017-01-23 14:44
For Doc- Couddb/ledger- Dave

weeds
2017-01-23 14:46
For Ledger- finish couch Miscellaneous items (versioning, deletes); Query expose to application chaincode; history of key values(level db) - add to QSCC, expose to application chaincode; Chaincode examples- table replacement, query, history

weeds
2017-01-23 14:46
for DOC- Gossary of terms- Nick, SCC- Murali

weeds
2017-01-23 14:47
----------------------here is where discussion has started-------------------------------------------

weeds
2017-01-23 14:48
To original list- experation of MSP certs

weeds
2017-01-23 14:50
what else on the list before we go through? (binh asked)

weeds
2017-01-23 14:50
Gari suggesting we go through first pass and eliminating pieces we should not go after

weeds
2017-01-23 14:51
let's do the list starting with TLS first and then Ledger, then SDK, fabric CA and whatever we decide will effect the docs

weeds
2017-01-23 14:51
TLS- the server side works and you can dynamically add certificates to it incrementally and that's all checked in---- Under BDD we added TLS

weeds
2017-01-23 14:52
Validation of messages and transactions- this is Ale's items, this is almost done

weeds
2017-01-23 14:54
Replay Attacks- Angelo indicated what we have committers check the transaction id is duplicated- only the committers, but we have to generate the transaction id, which we don't- so we had long discussion.. we agreed to generate a nonce and generate with creater's id and hash that.. that part is important. whether we can create the replay attacks or not may not be completed

weeds
2017-01-23 14:55
The discussion we had with murali is what if legacy software is using for application related- so generating for nonce of creator might not be accepted.

weeds
2017-01-23 14:58
Today- we need to solve replay attacks and mine the transaction id to the identity of the creator. We need to use the TX-ID generator- this is equal to the creator plus the nonce.. this has to be done prior to preventing replay.. SDK is already generating a transaction id,.. but it's not done in the way that is highlighted here. There as to be an adapter into a question- some event comes out- you call api and you can map the transaction id.. if you want to track it- pass it in as a parameter. The question is for doing it- if we are going to be consistent on the SDKs and you agree and creator + nonce- it's not a hard piece of work. are we going to do it or not? We do generate an ID today... the id is nonce so we have creator

weeds
2017-01-23 14:59
we will not do this for end of the month on transactionj id generator- creator + nonce

weeds
2017-01-23 15:00
Replication MSPs for gossip- basically we formatted a final document at end of last week, we need to close some edgers, but if enough time to talk with Elli, I will like Gari/Binh to review and after that- we can finish this out

weeds
2017-01-23 15:02
Anchor peers- upon channel creation, anchor is there, and we checked manually it works. I hav enot seen code that deels with configuration of stuff in peer when new configuration blocks comes from ordering service. and the adjacent manager config transaction is not in the peer. Jeff added that yesterday in BDD... he added the anchor peers in BDD. BUT we don't have a configuration handler on the peer side- without that, we can not deal with the configurations that are not associated with channel creation..... We also need to do extra work in the peer. We need to combine jeff's work.

weeds
2017-01-23 15:03
Board changes- Anchor config block with handler; BDD

weeds
2017-01-23 15:03
Channel Leader- basically the code that elects the leader is inside and has been merged since beginning of last week. the only thing missing is plugging into gossip. I have a chainset that I need to code review for this

weeds
2017-01-23 15:04
HSM (key generation)- Vlad said we need on key derivation... our proposal is to remove this from end of January.

ashutoshkumar
2017-01-23 15:05
last sentence is not clear.

weeds
2017-01-23 15:07
Chaincode Rerturn Object- We have a merge conflict and Murali is checking it right now.. we need to leave this here, but it's pretty close . WE are returning an object from protos that we effined a long time ago- now we are returning an object that we are returning code where we use HTTP return status code where 100's 200's 500's and a message in there and a payload (which is a byte array). This gives more flexibility for chaincode to return what is needed. If you ask me to endorse something and I need to kick off a workflow- I will return code saying incomplete,etc,.. ; SDK list is being updated

weeds
2017-01-23 15:07
SDK: added Update CC return object

weeds
2017-01-23 15:08
@ashutoshkumar we are making decisions on what we are going to get done for end of January for our Alpha/Beta code- we will not try to tackle completing the HSM work is the net. Clearly if open source team has it complete- we can relook at the decision, but we're trying to make sure we prioritize as we want to get very clean Docker images and compose scripts for members of the community who want to program and play with version 1.0

weeds
2017-01-23 15:08
I'm currently taking notes on the discussions here on what we should focus on among several people in community

weeds
2017-01-23 15:09
(not everyone is attending, so we are going to be looking for feedback to go to @binhn .. this is a first cut proposal)

ashutoshkumar
2017-01-23 15:09
thanks @weeds

weeds
2017-01-23 15:12
We need to add some additional work on chaincode return object- the remaining work after we merge this latest piece is to take the work Jim has done and completing it writing it down to the ledger. Why would you write the response down to the ledger? Not in the state base, but we would write in the transaction, so we can record the response code. We store events from chaincode into the ledger- so the worry was that we are getting all tehse responses and we are not saving it or persisting it. So it's not in the signed part of the block? The events are not in signed part of the block- yes they are in signed part of the block. Is it important to persist this information? If it's part of transaction and app is using it to make decisions, then it seems like it is important. In the query - we never send that so it really does not matter there. So if transaction id- what was the response? that one piece of information- we store everything in transaction, that could be important for auditing like chaincode events... Added "Transaction proto should contain repsonse"

weeds
2017-01-23 15:14
Chaincode endorsement policy: what kind of policies are we going to provide? My understanding is that you can specify bv VSCC in lifecycle chaincode- if you give complex policies- code validating is there... the code in CLI/SDK is not... you send request, at time of commitment, the code is there to query the lifecycle chaincode and to validate that all the people are signing off. Are we using same policy that we are in protos? We use one policy specification that Jason defined. When we complete whatever work in runtime and by specifying in SDK and SLI- that doe effect the SDK which we titled ESCC/VSDD.. When you do specify it, you have to serailze it into Jason's format. We should do this by Alpha.

weeds
2017-01-23 15:15
We need to check back with Ale on this

weeds
2017-01-23 15:17
Revisit Events- this is from Pat (community member). we need to do events from chain channels and hook it up for channels and hook it up with MSP. So we added Revisit events (channel &MSP) We should add security restriction because he's not authorized.. depends on how far we want to go. We need to confirm with Pat. @pmullaney We need to check with Pat and verify with him if we need to specify any additional policy or we use policy from the channel. The easiset thing is if we have read permission on channel, you get events. Based on my experience on how fast it works- the best we can hope for- backend he has chaincode and block events.. and he's working on SDK. i don't know if he can get the rejection events in and support for SDK. WE don't need rejection events. In 0.6 we had this- because invalid transactoins were not part of block- but now they are part of block and we have bit array that marks invalid transactions

weeds
2017-01-23 15:18
We do need to add the channel ID-- we don't think we will be able to do any security on revisit events in 8 days

weeds
2017-01-23 15:18
You have block come in- list of transaction. if they fail in MVCC/VSCC,.. we still add a bit aray filter that points to location of which ones were invalid. Basically means that we did not process a state change

weeds
2017-01-23 15:19
We do have ability to check for false/invalid transactions. that is always just there

weeds
2017-01-23 15:19
Do chaincode events get set for invalid transactions? Murali says today it is.. we should probably revisit this.

weeds
2017-01-23 15:20
He builds in handler, the api that does it-- on the orderer side- it has to have the exact same logic of whether you are on channel or not.. and it will process signature from MSP list. When Jason/Kostas gets that code and we can take the handler code and use it for the events. Jason and Kostas and that team will be able to probably do that faster for Pat

weeds
2017-01-23 15:20
to utilize

weeds
2017-01-23 15:22
Jim Zhang said we need to filter out the events for invalid transactions otherwise it may be really confusing... it is absolutely possible. the simplest way is that fabric won't send chaincode events. block has chaincode events. and SDK will do the parsing. SDK is already doing that today. events by transaction ids.. so you move that , Basically Jim will have to map for transaction id- you find out what #numberit was in the ordere and you check in bit array.

weeds
2017-01-23 15:22
We need to do post processing on the SDK

weeds
2017-01-23 15:23
Do we have a size limit? i know we have number of transactions, but do we have a size limit-- we have preferred max bytes and max bytes. it's 512K that's the preferred. I know it's north of 7 Megabytes... we need to revisit the block payload because it travels through the events like that. Pat is actually filtering out the deploy transaction and removing that and does not touch the other stuff yet and we need to make sure he's aware. I would prefer only transaction ids and events, but then they have to go back due to security.

weeds
2017-01-23 15:25
Chaincode lifecycle- do we want to redo the deployment and upgrade? We need to make a decision on this today or tomorrow. the policy is done- Kostas said he needs to ask Jason . this is chaincode policy who can deploy and manipulate the lifecycle when creating the channel . It is the deployment of the chaincode- who can deploy chaincode on the channel? We have some control on who can deploy and upgrade on the chaincode?

weeds
2017-01-23 15:27
There is a proposal on how we deploy chaincode- and we need to decide. There are two parts of it,.. so we are highlighting chaincode life-cycle as a quesiton mark.

weeds
2017-01-23 15:28
Error handling- we have the base, but everyone needs to use this. The base - we have code at the right place to encapsulate the stack trace.. if there is an error- and that error code indicates the components .. so you know this is chaincode error, or this is peer error, or this is orderer. The framework is done but not all components has used it. Peer has done some of this. - define error codes for component

weeds
2017-01-23 15:29
Error handling is going to happen from now until GA honestly

weeds
2017-01-23 15:29
(GA is a relative word here,.. but it's when the fabric is stabilized for production use, which is dependent on quality work being completed)

weeds
2017-01-23 15:33
Bootstrap with predefined channel-- We have hardcoded in our code that we start up with a channel,.. but I'd rather do that as configuraiton out of the code. if we specify the configuration and we start it up with a configuration versus bake it into the code. In other words you don't create cli or SDK... you look at config- they need channel test id to start up and then we create it. rather than we have it in the code. This assumes that we have ability in orderer and predefine in channel and genesis block and use with the peer. We have to have block from orderer. The orderer has to start the config block and they need to know members.. We just need to have a default thing that people start with. This whole process is security based.. we haven't configured the orderers MSPs properly. . In our code we automatically create test channel-- that is the point. If that needs to go, we need to startup with channel for programming. We need to come up with dev mode kind of thing.. Easy to say create channel in peer, but I also need channel in orderer. This is where the complication is. The current feature will bootstrap system in 4 seconds. having a test id channel- the user test - i would just get rid of everything and it confuses everything. We need to come up with a way- a nice simple way in the bootstrapping feature scenario how we have a system come up for people that is working,.. and we can do that.

weeds
2017-01-23 15:34
BDD has a lot of this

nagasurya
2017-01-23 15:36
has joined #fabric-dev

weeds
2017-01-23 15:36
I worked hard on this- we should not shortcut ever-- for developers, to bring up system, we can't tell them to run BDD. But we can make that easier to do. So what we want is a CLI to bring up a system for development.. jeff stated tweeksk knobs parameters is pretty complex 27 steps- and there is a tweek in everything orderer, peer id, the signers, the developers,.. then creation policy, who are your anchors... someone is going to write it just like feature file.. but our test could just be the script. This is a full blown interactive... WE are going to hackfest and we want people to have a simple way to do this

weeds
2017-01-23 15:37
The test chain id has to be in orderer- and this is bad part- having hard coded test chain id in orderer is bad.. in dev environment, we need to prime it in dev environment and not hardcoded in environment. So we are getting in design discussions..

weeds
2017-01-23 15:38
let's take this off line-- we are going through this list, but we want people to do something on the 31st- orderer comes up and peer comes up- create channel api and I get you default certificate, create channel, and add one org and the stuff should just work-- that is what is a development system..

weeds
2017-01-23 15:39
ARe we telling developers that they ned to set up our system- vagrant and everything to run BDD-- NO.. Behave stuff only requires docker compose period... there are a million ways to do this-- so we want to get to prove this out and where this is consumable is to eliminate hard coded stuff and if it doesn't work, then we need to go fix it...

weeds
2017-01-23 15:40
Bootstrap with a channel for dev- Jeff Garrat is going to do this and work with Gari/Jim...

weeds
2017-01-23 15:40
there are simplist- CLI,. SDK .. the usre wants to do something more complex with BDD.. the test chain id we need to remove and make it simple

weeds
2017-01-23 15:40
I worry about concept of having a separate network that is for developer mode- i think those days are gone. in that case you provide sample ceritifcates and run through the process. no more shortcuts--

weeds
2017-01-23 15:41
all keys loaded from files,etc,.. even SDK is doing that now... Jeff made important point there are 2 main places we are hard coding- test chain code id... certs was hardcoded- we still have a sample out there- we generate using bdd and this is directory or use directory already shipping

weeds
2017-01-23 15:42
Custom Transactions- not for end of Jan

weeds
2017-01-23 15:42
CLI accepts multiple peers; we need this to test endorsement policy

weeds
2017-01-23 15:42
App crypto lib- this is a run at for alpha

weeds
2017-01-23 15:42
system chaincode refactor- this is eash given Ale's work

weeds
2017-01-23 15:42
Chaincode calling chaincode- we have addresswed the query case

weeds
2017-01-23 15:43
QUERY CASE only on CC calling CC

weeds
2017-01-23 15:43
Exsperiation MSP certs- we will not address this for alpha

weeds
2017-01-23 15:43
------------------------------------

weeds
2017-01-23 15:43
For SDK (node.js, Java)

weeds
2017-01-23 15:44
The master is still on 0.6.,engaging with DTCC- we have created a 1.0 branch that we want to be master.

weeds
2017-01-23 15:44
We are having to merge this.

weeds
2017-01-23 15:44
Between DTCC and those on phone- there is also another guy from Fujitsu we need to merge everything

weeds
2017-01-23 15:45
Java only: create "official" branch. #1 does not have to be done by end of htis month, but we do need to "clean" the directories up

weeds
2017-01-23 15:45
and that is being worked on to ensure we have clean consolidation

weeds
2017-01-23 15:45
Events support- Jim Zhang needs to talk about the eventing piece with Pat (see discussion above )

weeds
2017-01-23 15:46
Rest Wrapper- we have now handed off to the team that has joined the community in Hursley to do this

weeds
2017-01-23 15:46
GRPC for Join is in there- Brett has committed that- but we have trouble with MSP definitions

weeds
2017-01-23 15:46
it fails at that point- but we are getting all the way through the GRPC aspect

weeds
2017-01-23 15:47
ChainQuery on Ledger- The api is available in GO code is there, but it is not there for GRPC.. pass through query

weeds
2017-01-23 15:47
chaincode join- synce it's system chaincode call you can copy a lot of logic on query on ledger to complete this

weeds
2017-01-23 15:48
Remove RSA and HSM for SDK goal for end of month

weeds
2017-01-23 15:50
We have the Go implementationfor TCERT- we have the TCERT derivation form the last implementation is there. It takes a key derivation on the SDK side and it's exactly the same.. we can maybe get there and Gari Singh can help that

weeds
2017-01-23 15:50
@jonathanlevi please make sure you read the fabric-dev channel as I know you are helping on many of these pieces- (this is a side note)

weeds
2017-01-23 15:50
ESCC/VSCC- we need to add reference to a name in the proposal and we can do that

weeds
2017-01-23 15:51
For query on ledger- this is just AP that you already call on channel join, but we are down to 2 1/2 to 3 developers.. on priority list query on ledger seems low. can't clients call system chaincode on any special thing on SDK.. they can also do from query CLi and get it

jonathanlevi
2017-01-23 15:51
@weeds: Sure thing.

weeds
2017-01-23 15:51
Jim is probably going to x out query on ledger

weeds
2017-01-23 15:52
SDK already accepts multiple peers (this was a question).

weeds
2017-01-23 15:53
--------

weeds
2017-01-23 15:53
For ledger- finishing couch misc items (versioningk deletes)

weeds
2017-01-23 15:53
Query APi is already exposed, but need to do work related to application chaincode-

weeds
2017-01-23 15:53
WE are in middle of history of key values (level db)

weeds
2017-01-23 15:53
We started doing the work on couch for history of key values and pushed down into level so that everyone can have the history not juts couch people

weeds
2017-01-23 15:54
For couch- we do not support remote- we will only support local to the peer

weeds
2017-01-23 15:54
Finalize QSCC block/tran structure that gets returned to client has to be discussed between Binh/Dave.. we definitely won't get through examples, but we may try to go through table replacement/query as we can before end of next week

weeds
2017-01-23 15:54
@manish-sethi wanted to make sure you are reading the channel here- see all up above and start of conversation

weeds
2017-01-23 15:55
maybe Mohan can help with examples possibly?

weeds
2017-01-23 15:55
-------------------

weeds
2017-01-23 15:55
For fabric- CA

weeds
2017-01-23 15:55
comments on the list from up above

weeds
2017-01-23 15:55
Keith is trying to generate the swagger

weeds
2017-01-23 15:57
We need to decide on whether we do something on HSM support or later-- I think we decided that we are not committing HSM for alpha but HSM support (BCCSP or let's ecnrypt) - the way i'm leveraging- i want to use BCCSP integration throughout and then get HSM support through BCCSP. there are multiple places for private keys- signing of CSR request, singing of authoization header, signing of TCERts.. thing that is where we need to do the integration. We already have BCCSP config integrated in. The thing unclear right now is can we assume if we have BCCSP integration then we do have HSM support or no?

weeds
2017-01-23 15:57
Vlad is going to have to clarrify

weeds
2017-01-23 15:58
We want to do HSM support on BCCSP

weeds
2017-01-23 15:58
Vlad had done CFFSL has their own layer of singer on top

weeds
2017-01-23 15:59
@vpaprots see above

weeds
2017-01-23 15:59
you have to send future request, they are authenticated in authorization header that covers certificate.. and it contains sig, the sig contains the signature and the body. we need to do the signing wiht VSCSP..

weeds
2017-01-23 15:59
the signing in our CLI client

weeds
2017-01-23 16:00
if we did on the server side- it does not mean that yo uhave to do at the same time as the SDK side

weeds
2017-01-23 16:01
It comes down to request and re-enroll . On the CA side, the CA is some refactoring but perspective of using it, it works. so we need to finish the register from SDK- we have almost ready to check in,.. by default we use SHA384 (only register/reneroll for off token),.. we would have register and create new users, enroll already works beautifully (Jim integrated it).. we enroll and get cert back.. no more work on SDK side for that.

weeds
2017-01-23 16:02
We just need to finish register and re-enroll.. do we take a cut. if you want to do a few things to clean up the document, it does not stop doing additional work. and we just take a cut of the CA before. so we can merge stuff after that.. and CA is in very good shape.

weeds
2017-01-23 16:03
The only thing that is merged with HSM support for BCCSP.. BCCSP you can configure but it's not being used for HSM yet. Just like HSM is out of the peer. You know that the default you changed to 256- so this is hard coded.. I di dnot change I implemented to SHA 384.. it's hard coded today so we can't change it.

weeds
2017-01-23 16:04
Intermediate CA support- I assume that is something that could wait, but i put that up there because the place where this is nice- if you set up a cluster of cop servers or fabric ca servers and you want to get enrollment certs distributed for them. you can start a root ca and cluster of intermediate servers that enroll with it.. I may be overly optimistic- this is 1 day's worth of work. it's not a big effort. Binh is saying this is very useful for testing out multiple MSP concept. it will be nice to have a single ca and generate something intermediate. IT's also nice to reknew a CA certificate ultimately.

weeds
2017-01-23 16:05
if you do the first thing with Swagger doc.. and top list. if we are willing that SDk is not complete- you can use ecerts we have that working.. we have ability to node sdk to enroll, we finish register api, cop is up- you can get certificates fo rany # of peers for encorsement and for joining channels and connecting. We can use what Keith gets done. but we can take CA and build that out today and use that for the 31st.

weeds
2017-01-23 16:05
If we don't have TCERT support throughout- that's fine

weeds
2017-01-23 16:06
--------------

weeds
2017-01-23 16:06
For documentation

weeds
2017-01-23 16:08
We should have remove the version 0.6,... we are already started on high level overview, high level architecture, glossary of terms, how to get docker up and running with compose,.. and how developers program against chaincode -- which includes APIs, channels, couchdb/ledger and chaincode.

weeds
2017-01-23 16:08
Binh asking how much more we need to help on doc based on where we are- i need the apis and how to program against chaincode with Murali... Murali will sit with a couple of hours to step through all that stuff

weeds
2017-01-23 16:09
need to have some prebuilt things- x number of the MSP- -we should at minimum in policy have that... for the docuementation things like query system chaincode, config system chaincode,

weeds
2017-01-23 16:10
docker compose is self descriptive instead of reams of documentation-- just explain like was done before

weeds
2017-01-23 16:10
@nickgaski @joshhus

weeds
2017-01-23 16:11
Today we have sample config- we should have sifferent sample config and put them-- and use docker compose

weeds
2017-01-23 16:11
and we generate the sample config

weeds
2017-01-23 16:11
What does it mean to have identity to invoke chaincode? ours is a permissioned ledger.. this is important concept.. but we need to at least need to highlight that.. wecan go into details in MSP, but at minimum this should be outlined.

weeds
2017-01-23 16:11
How can I use to invoke chaincode?

weeds
2017-01-23 16:12
How about we have one config and config has identities that are pre-generated and we describe how we got identities and the places we are going to use

weeds
2017-01-23 16:13
This is trying to explain the initial set for end of this month and starts to be the framework- i agree that a high level description of how membership is enforced- explain permissions are organization based, we will have notion of membership defined via crypto mechanisms and x509 based support and here is a simple paragraph on that

weeds
2017-01-23 16:14
We then at end of this month- you want multiple orgs- each has x509 certificate- here is what you need to gather and we have worked out in api the config transaction for create channel has that MSP config struct. we make it simple at high level that the basics have MSP name plus the pem certificate and this is how it works. Then we can add more as we go along- it gives you the basic framework to start wtih

weeds
2017-01-23 16:14
In addition with that- we do some configurations for reference- we provide with 3 organizaitons and here is 3 root certificate authorities and an MSP policy that is 2 out of 3 for endorsement and have at it. @bmos299

weeds
2017-01-23 16:15
Angelo indicated that we already have a lot of this written up- so Nick and Josh can pick up from the dock from Elli and team

weeds
2017-01-23 16:15
----------------------------

weeds
2017-01-23 16:16
What I want to do- put your name on the items on the board and you work on it-- I want to have a standup scrum at 3pm today where I will transcript again here on the fabric-dev channel. We will only do 2 things- what are the things preventing you from progressing? we will then keep people who need.

weeds
2017-01-23 16:16
we will do this at 9:30 and 3pm and will post on the channel

weeds
2017-01-23 16:17
if there is feedback from any of the items above from those not involved in discussion (where there were many)- please get with squad laters or Gari Singh or Binh Nguyen

weeds
2017-01-23 16:19
With Clayton- we will take a quick break- we want to have discussion with Keith, Jim, and Binh so we talk about the scenario on how we use this- what is it that we expect to do on February 1st

weeds
2017-01-23 16:19
This may further refine the list up above- again we should ask that the community contribute to what we have written here

weeds
2017-01-23 16:19
----------------------

weeds
2017-01-23 16:26
@markparz highlighting that you need to read the channel

weeds
2017-01-23 16:27
-----------------------

weeds
2017-01-23 16:28
We have drawn a pic on the board

weeds
2017-01-23 16:29
Boxes are fabric-ca, orderer(solo), peer, SDK/App

weeds
2017-01-23 16:29
We want someone to be able to program and use the fabric at end of month

weeds
2017-01-23 16:31
Solo needs to come up- so someone needs to call create channel. There has to be a CA/Id that the orderer has to trust

weeds
2017-01-23 16:32
From SDK you must be able to create channel (orderer) and join channel (peer)

weeds
2017-01-23 16:33
Let's assume that we have multiple peers/cc 's

weeds
2017-01-23 16:33
We have multiple peers/cc

weeds
2017-01-23 16:33
Org1 peer, org 2peer, org 3peer

weeds
2017-01-23 16:35
in orderer- you have config block (chain name, address of orderer, msp config- cert/anchor peer.. cert/anchor,. cert/anchor)

weeds
2017-01-23 16:36
if we agree to this- the end scenario is that your application to prove out more than our single endorser..

weeds
2017-01-23 16:37
We have definition of create channel and taking in MSP config is in there.. but the orderer is not reading it; for create channel- the orderer takes what SDK channel takes so we have to come up with the right materials... jeff has it on the screen as he worked it. The only thing missing orderer is not taking generated MSP information- i already do it on the peer side.

weeds
2017-01-23 16:38
Does the peer itself write to the block? yes.. does the peer load any of the information and loads into the channel MSP config and utilize for cert config

weeds
2017-01-23 16:38
Current policy one of all members of the channel

weeds
2017-01-23 16:38
Then why do we have to do any additional work for January 31st?

weeds
2017-01-23 16:39
The local MSP for orderer.. do i care if orderer signs messages... the high level scenario write chaincode, deploy chaincode, and use basic policy that is more than one guy endorsing it.. 1 of MSP configured for channel

weeds
2017-01-23 16:39
All the info is in messages ...

weeds
2017-01-23 16:39
If you don't need access control- then we are done

weeds
2017-01-23 16:40
simple scenario that works-- all the stuff surrounding it that we need to have some level of code, because in February we really need to start testing.

weeds
2017-01-23 16:40
If I want to have someone use this thing- is it useable now and prove out basics of system. What is missing? should we just do doc improvement on this scenario?

weeds
2017-01-23 16:41
WE can work on how we integrate the CA into scenario.. and process of SDK can utilize what Jeff did in his script already showing this scenario work.

weeds
2017-01-23 16:41
If changes to from last week- too many merges can happen... and can hurt us

weeds
2017-01-23 16:42
We should probably have ability to create multiple channels---

weeds
2017-01-23 16:42
(this works)

weeds
2017-01-23 16:42
@bmoss299 we should make sure that this scenario up above is what is documented by Nick/Josh

weeds
2017-01-23 16:43
Do we want to show negative checking? do we need to verify endorsements? it would be trivial to add a user that is not signed by cas that is not accepted by channel creation and that works-

weeds
2017-01-23 16:43
for SDK to do the precheck- we need MSP on backend to be done and we do need work on SDK

weeds
2017-01-23 16:44
Brett seems to be working on join channel... we need to publish those as mpms alpha version. you want to have a sample

weeds
2017-01-23 16:44
on sample i would separate out deploy/invoke- here is how you create/join channel and here's how you deploy and invoke chaincode.

weeds
2017-01-23 16:44
It can fail any one of those processes, but it helps to see those steps. we are in better shape than thought. We should take this same scenario

weeds
2017-01-23 16:45
now we decide we add TLS or add authentication by ordering side and we should then iterate... we use the images from what we have

weeds
2017-01-23 16:45
we could tag a version of master and build the images from there

weeds
2017-01-23 16:45
----------

weeds
2017-01-23 16:45
Current behave images- effectively the top part is the CA definition- you can see defined order nnetwork (only signle organization)

weeds
2017-01-23 16:46
we have process a subject, a context, and a signer.. even though different verbiage we have admin tuple- cert from subject for context given an org

weeds
2017-01-23 16:46
this guy orderer0signer, order0o, orderorg() this is cert that puts under orderer when it starts- we can pass the yaml file to orderer. you will have local MSPs

weeds
2017-01-23 16:46
all that information is passed around

weeds
2017-01-23 16:46
ordererOrg()- this points to org that points to pem file with self sgining

weeds
2017-01-23 16:47
in scenario- we can decide if we do 3 cops- we can integrate that into scenario.. we can use ca for short

weeds
2017-01-23 16:47
this minimizes and nick can improve on docs... Jeff feels he can generate docs dynamically

weeds
2017-01-23 16:48
on volume- i'm going to output all the key artifacts

weeds
2017-01-23 16:48
so organization- all key organizations you want to define, ie peer org2

weeds
2017-01-23 16:48
So now you have afccess to the organization- orderer generates the GUId- so ordersystemcainid... so we utilize this name

weeds
2017-01-23 16:49
then bootstram creates chain policy- so basically i'm creating policy so thhree orgs can create channels , ie peer org0, 1/3

weeds
2017-01-23 16:49
so now signed items are created-- and now we have to create the msp using that policy (chaincreate policy 1)

weeds
2017-01-23 16:49
Now you have to create the genesis block for that chain id using policy solo and referencing all tehse policies and associated names

weeds
2017-01-23 16:50
chain creator does enforce that in that msp based on whatever that policy is

weeds
2017-01-23 16:50
that creates the genesis block

weeds
2017-01-23 16:51
We are missing a step instead of guy creating a block- the guy has to create the block data and collects signature on the orderer just like developer- orderer has to get the sigs if there is one org or multiple org in orderer. but we have to add that

weeds
2017-01-23 16:51
But none of that is enforced today- no, but I don't want to miss it

weeds
2017-01-23 16:51
so you tell that story- how we have to incrementally plug those features in

weeds
2017-01-23 16:51
couple of other things- and this thing i'm defining th e peer network- this generates signer certs to each peer and peer starts with right local msp

weeds
2017-01-23 16:52
i gave peer 0 to peerorg0 but peer 2 and 3 peer 2 in org 1, peer 3 in org 1

weeds
2017-01-23 16:52
this is template stuff--

weeds
2017-01-23 16:52
the next thing we do is identify developer for peer organization- give a subject and give context chaincreate policy1 (the one we gave to orderer)

weeds
2017-01-23 16:52
this is like giving developer access to a space- because I don't want anyone using the peer certs .. this gives sdk it's own identity as example

weeds
2017-01-23 16:53
peer org signs and devleoping in this space which we call chain create policy1

weeds
2017-01-23 16:53
I need identities for organization- so i chose peerorg0 and peerorg1 and this is subset of the genesis block- I could limit my channels to single org or subset of the org-

weeds
2017-01-23 16:54
if you have create chain policy- you can add any org you want.. because it has to be in the orderers- right now it does.. how can they validate it. how can they verify the sig. they do verify sigs. you verify signatures of public but it has to be in trusted root

weeds
2017-01-23 16:54
if i have create chain- theat everybody in this list-everyone has to sign it- so you have signature across the bytes, but remember these are the peerorgs you are asking for endorsement from

weeds
2017-01-23 16:56
cft ordering system- there has to be at simplest- you have to then decide continue certs .. so you have to have one guy must add a bunch of root cas of who can do a create channel . now I am allowed to create channels i should not have list and should go out and pick 15 other people as long as signed by those CAs ...

weeds
2017-01-23 16:56
acceptance of block- i inspect,... or never join acceptance without signing. at what point will orderer enforce his certification. On broadcast

weeds
2017-01-23 16:56
IN this scneario- we are defining the peer organizations before we bootstrap the orderer. the reason we are doing that is we don't support the reconfiguration. so now who are the endorsements and particpate in the channel i'm going to create

weeds
2017-01-23 16:57
i create peer anchor set and I'm saying my anchor is from peer org 0, peer 2 from peer org 1 so I'm picking 1 out of each group

weeds
2017-01-23 16:57
i crate signed envelope- i have to reference channel, template, chain creation policy name and the anchor

weeds
2017-01-23 16:58
Thetemplate is a reference to the ones I'm going to use that i defined,.. chaincreate policy1 is a logical name must be used in all channel creation

weeds
2017-01-23 16:59
So now i get my signed config envelope- the orderer should ask all the order to sign before genesis block- org 0 collects signatures ...

weeds
2017-01-23 16:59
now create config transaction using signed above

weeds
2017-01-23 16:59
i save as configtx1 and broadcast to orderer

weeds
2017-01-23 16:59
I wait

weeds
2017-01-23 17:00
then i connect to deliver fucnation and seek request with those properties with chainid

weeds
2017-01-23 17:00
i should get delivery from order0 in 1 block within 1 second

weeds
2017-01-23 17:00
i then request to join using genseis block on peer 0 with result

weeds
2017-01-23 17:00
I am calling api on system chaincode

weeds
2017-01-23 17:00
then let's say it works (which it deos

weeds
2017-01-23 17:01
now i'm delivering waiting and what does happen- we got a 200 response from peer

weeds
2017-01-23 17:02
for information on immediate up above Jeff Garrat can help

weeds
2017-01-23 17:02
the only thing that is not there orderer is not using the cert available to it (peer does this already so similar code)

weeds
2017-01-23 17:02
I just need to deploy and have code in deploy and ask for multiple endorsements at the same time

weeds
2017-01-23 17:03
lot of steps to get network up and running

weeds
2017-01-23 17:03
my docker network is running and you can use cli

weeds
2017-01-23 17:03
but developer should not run bdd- they should just run docker compose

weeds
2017-01-23 17:03
it's more involved than that, because under the covers, i'm creating genesis file dynamically and also generating the local msp

weeds
2017-01-23 17:03
so i create ca certs, pstore and parameterized

weeds
2017-01-23 17:04
docker compose can bring up entities unles syou hard code- so now you need scripts to link them together

weeds
2017-01-23 17:04
We have to do the work on SDK sde to make this work and they should replicate this

weeds
2017-01-23 17:04
ARe you saying angelo we support one of msp policy today- we do on VSCC

weeds
2017-01-23 17:05
do you define that at the ESCC side? they do have to match but we have the one of

weeds
2017-01-23 17:05
and does that work when you deploy chaincode- we have to work that- which is chaincode lifecycle

weeds
2017-01-23 17:05
which is in the list

weeds
2017-01-23 17:05
we have everything to joined channel and we can inject deployment

weeds
2017-01-23 17:05
but deployment not ready yet

weeds
2017-01-23 17:05
to deploy chaincode- you need one of policy--- we need that

weeds
2017-01-23 17:06
if we expect people to not break apis' we probably need chaincode return object

weeds
2017-01-23 17:06
it is implemented but merged and committed and documented

weeds
2017-01-23 17:06
you need deploy transaction and need in SDK to specify the ESCC policy

weeds
2017-01-23 17:07
Jeff- if i look at the log for gossip peer- which is peer 1- i see something that is concerning-

weeds
2017-01-23 17:07
there is "no such channel" on the anchor

weeds
2017-01-23 17:09
i would tag master and build and go through 20 steps and everything provisioned

weeds
2017-01-23 17:10
there is a mismatch in gossip and way we are encoding

weeds
2017-01-23 17:10
VSCC would only check to see if one of members is singing

weeds
2017-01-23 17:12
Things for absolute minimum- chaincode return object, chaincode endorsement policy, escc/VSCC, events support (includ rejection ), chainjoin (creation basically needs to get done)

weeds
2017-01-23 17:15
The rest of the other items should progress- but we know what the most important it is

weeds
2017-01-23 17:16
The other piece we MUST decide on is chaincode lifecycle

weeds
2017-01-23 17:16
@ghaskins please make sure to read this channel- lots of discussion today

ghaskins
2017-01-23 17:16
holy cow, that is a big backlog, heh

weeds
2017-01-23 17:18
i don't know that I have everyone marked and i tired to put --- in at the places where we sto;ped and talked different topics

weeds
2017-01-23 17:18
and can't say anything about my spelling -

weeds
2017-01-23 17:18
:wink:

ghaskins
2017-01-23 17:19
I havent had a chance to digest all of that, but fwiw, I am currently driving a few areas related to busybox/dns fixes, devmode deployment via SDK, chaintool CAR deployment via SDK, chaintool support for v1.0, and cleanup of the chaincode deployment logic in general

ghaskins
2017-01-23 17:20
(much of which I already have completed but it hasnt yet been merged or submitted

ghaskins
2017-01-23 17:20
that will be happening over the next few days

ry
2017-01-23 17:21
@weeds @ghaskins that will be on the wiki soon

ry
2017-01-23 17:25
@weeds what is the context for this?


weeds
2017-01-23 18:33
@ry Binh met with several people that develop on the fabric

weeds
2017-01-23 18:34
We already have docker images that people can utilize (not sure it's all checked in), but we wnat to make sure for the hackfest that we have all the right pieces for people to

weeds
2017-01-23 18:34
1) start up the fabric

weeds
2017-01-23 18:34
2) be able to bootstrap a network

weeds
2017-01-23 18:35
3) be able to join, create and deploy chaincode on multiple chains based on who is allowed to be in that channel (ie we have multichannels working)

weeds
2017-01-23 18:36
4) they should be able to do the full transaction from sending transactions to the endorsers (where a policy is set- for example one out four endorsers can approve the transaction), be able to send to orderer and have it ordered and then put into the ledger (whether couchdb or level db).. they should be able to query the result---> this should be able to be done against multiple channels

weeds
2017-01-23 18:36
5) who is allowed on the channel is important part of scenario

weeds
2017-01-23 18:37
As a result the items above- we took assessment where all the pieces are in the fabric (there are some holes as not everyone anted up information during hte call)... and highlighted what we thought we needed to be done. So you will see categories of fabric, SDK, BDD (for testing) , documentation, and cop

weeds
2017-01-23 18:37
after that, and this is probably where the notes got fuzzy, Jeff Garrat took us through BDD showing how to bootstrap the network

weeds
2017-01-23 18:38
as this is already working and flowing an what minor pieces just need to be completed there

ry
2017-01-23 18:46
Belay that, I mis-remembered that

weeds
2017-01-23 19:01
To be clear- not everyone from community has inputted on this ... but if there is input- would be good to get it.. to ensure everyone has right priorities.

karl.e
2017-01-23 20:51
Hi, I recently added support for "PortBindings" in vm.docker.hostConfig. What would be the best way to submit a patch to you guys? It's single digit LOC.

drteck
2017-01-23 20:57
has joined #fabric-dev

sstone1
2017-01-23 21:15
has joined #fabric-dev

ghaskins
2017-01-23 21:15
@karl.e awesome, welcome to the project


ghaskins
2017-01-23 21:16
in short, we use Gerrit...its all documented in there. Ping back if anything isnt clear

weeds
2017-01-23 21:20
another quick conversation--> Now the thing that we can do, we can run Jeff Garrat's BDD- capture the block, put in sample directory and we run with that. That allows our CLI to work,.. that would allow the demo scenario to work with the new configuration block. With that configuration block- what would we have to do to submit that transaction to the orderer. Have you look at config txt template stuff? Basically there is under config tx test thereis order template file and peer template file. This is the statically exported thing (not fromjeff's tool) this is configuration tool.. and feed in new chain- and spits out the transaction you have to spit it out to create a new chain- there is no import cycles,etc,..

weeds
2017-01-23 21:21
So what if you did this? bring up compose, another docker container we boot up and tells people to console into it (exec batch into it).. it has the CLi and it has a series of commands... it can be any of those things. You can log into xyz, you run CDE,.. and then your thing is initialized an dyou can run your nodejs.sdk to run your transactions. People just have a hard time running CLI-- it allows us to use docker and not vagrant. Have a CLI container and do stuff. We just add additional commands- this is admin configuring the network. So you want to create chain and here's what you do.

weeds
2017-01-23 21:21
We can do that easily without channel create. and specify flag default cahnnel, use your template.

weeds
2017-01-23 21:22
You can actually do interactive- whatever command you run- you run batch script and then test just exec docker and run as a command line and without invoking the container- htat is how we did this last week, we put it in a container

weeds
2017-01-23 21:22
As long as we don't hardcode, but include the "generation part"... how many templates... let's just cli create to take argument where CLI chain create command will it do it for you.. we will call the templates

weeds
2017-01-23 21:23
so now on board -- we are adding CLI channel create for alpha

weeds
2017-01-23 21:24
Jeff has this working in behave- it's completely parameterized.. you get a language- you can add orgs, change orgs, create as many channels you want, create as many order networks.... will we intimidate developers to do that... Jeff says- it would be good to do a python setup .. you can clone the get... Actually, what we should really do is bake into the image.. Behave stuff drives docker compose.. and you can drive docker.. bind in the docker socket.

ghaskins
2017-01-23 21:24
@vpaprots @harrijk @ramesh regarding: https://gerrit.hyperledger.org/r/#/c/4359/

ghaskins
2017-01-23 21:24
how do we want to proceed ?

vpaprots
2017-01-23 21:25
talking with John atm..

ghaskins
2017-01-23 21:25
ok

ghaskins
2017-01-23 21:25
ill look to you guys: if you come back and are confident my concerns are unfounded, ill remove my -2

vpaprots
2017-01-23 21:25
John showed me that softhsm was not installed.. and I forgot that its debian..

harrijk
2017-01-23 21:26
I think for the first step, we'll need to get softhsm2 into testenv for fabric

ghaskins
2017-01-23 21:26
ok, thats a very low-risk proposition from my perspective

vpaprots
2017-01-23 21:26
I do need it in asap, sitting on quite the few changes that cant go in without it.. but.. found some issues with how I specify pkcs11-slot.

weeds
2017-01-23 21:26
what is important is they need to have an admin thing that is clear-- so the only way to build an app is to use the SDK.. we should have two simple scripts that create channel to call the apis-- just to make it easy.

ghaskins
2017-01-23 21:27
(sorry weeds, cross-talked over your stream of consciousness ;)

weeds
2017-01-23 21:28
We are set on CLI and run clis in an interactive docker container. So we are going to modify channel create.. it will take default template and use it as the configuration (it's ok greg- just trying to capture discussion here for your guys- can't tell if you can even follow the stream of consciousness)

ghaskins
2017-01-23 21:28
understood, just apologizing for interrupting it

weeds
2017-01-23 21:29
Jason- how would in default template get cert--- you would have to regenerate the template. Basically the tool that I keep alluding to essentially is order admin tool that connects to and dumps a template chain by looking at the block

weeds
2017-01-23 21:30
The tool does not exist- there is a static tool that exists, but we need this to work at run time. then we would check template in and can be generated... as part of the compose once you are running services which dumps template and would be fed into chain creation tool

weeds
2017-01-23 21:31
My developer needs a private key- we self generate all that stuff. we will have docker image for the cli.. so we could just use a shared volume to the local msp which is needed for that key and bake it in ahead of time... hmmm. the one jeff does bdd does it through shared volumes. someone is outside of docker writing a node app.. he has to find stuff.. if we just started a container rather than docker run, we can do docker exec,.. you could template, keys being there,etc,..

weeds
2017-01-23 21:33
in their application, where do we get their certificate from- there in a shared volume- they are on local file system,,.. you could put that in... that would be the easiest thing to do.. REally Jason said he needs to talk about the SDK guys - they really should not know how to do that and pick up from template and be able to print them,. .for now it's an efficiency, because we only have templates working is in go.. but that really should be in sdk at this point

weeds
2017-01-23 21:33
Binh suggested maybe give them an api to implement? Jason said- ok.. give them an api to use the templates we generate. Open a JIRA or slack it to them? Slack it to them.

weeds
2017-01-23 21:34
Barry- maybe I have Latitia to help you? Jason- I would love to get more people to know how this works. It's tying hte config and node program and spinning up something quickly.

weeds
2017-01-23 21:34
(we need to forget not to miss the java sdk)

weeds
2017-01-23 21:35
There are some questions for Jim in terms of validation process for Barry and Latitia

weeds
2017-01-23 21:35
We have an image, spins up fabric, runs templates,.. which crypto mounted to volume and then tell sdk here is how you connect and use this.

weeds
2017-01-23 21:37
Just to get someone writing ... the thing with say I had another image he spins everything up and it's a done deal for me- i have all certs and network. if I run a behave (instead of the cli) run the docker image that runs the behave- we mount that.. in behave, you would have to generate all the cert stuff.. it will do it for you.. we just tell the end user.. hey sdk developer- yo uare ready to go. If you just basically toe do not decompose.. if you can get an image.. put. now we can hardcode behave .. maybe that's an easier fix.

weeds
2017-01-23 21:38
Which is better? at end of the day, people are going to have to know how to create the configuration transaction and you won't have all your stuff in one place and you will have to deal with templates... Yes, that's true.

weeds
2017-01-23 21:38
The big thing is can you make behave from inside a docker container-- that's going to be the question- you can bind docker socket into docker image. That's unit test, but Jeff might know.

ghaskins
2017-01-23 21:48
@weeds: on that front, it was my intention, though I have yet to prove it out that "make behave" would eventually drive the behave tests with a "$(DRUN) behave", similar to how we do unit tests

ghaskins
2017-01-23 21:49
as part of that, I would be moving the python installation stuff that we currently do in the baseimage to be within the testenv container that is JITted as part of the build

ghaskins
2017-01-23 21:50
from there, it should be straight forward to grant the behave container permissions to dockerd for its own control of futher containers, similar to what we do in other places

ghaskins
2017-01-23 21:50
but where I am going with this is: I woulnt classify it as "make behave" running in a container, as much as "make behave" drives behave within docker

ghaskins
2017-01-23 21:50
thats probably the same thing you meant, but good to clarify

binhn
2017-01-24 02:15
@ghaskins :+1: We were talking about what would be the best way to help app developers set up a working environment, and the thought was to run a bdd feature (pick an appropriate one)

ghaskins
2017-01-24 02:16
ah, as in use bdd to help create an app developer environment?

binhn
2017-01-24 02:17
yes, but we wouldn’t want developers to have to install vagrant + other tools, just bring up a docker image to run the bdd from it

ghaskins
2017-01-24 02:17
ok, but we are already largely there, arent we ?

ghaskins
2017-01-24 02:18
the majority of functions (excluding bdd) only need make/git/docker/docker-compose

ghaskins
2017-01-24 02:18
and I think bdd could be brought into that fold fairly easily

ghaskins
2017-01-24 02:19
some of what you are talking about reminds me of this old issue: https://github.com/hyperledger/fabric-chaintool/issues/5

binhn
2017-01-24 02:19
i think the work is to enable bdd inside a container to create images and launch other containers

ghaskins
2017-01-24 02:20
I was envisioning a user doing something like "chaintool new" and it will spit out a skeleton chaincode app

ghaskins
2017-01-24 02:21
it would be fairly easy to make different profiles that are both CCI based and those that are not

ghaskins
2017-01-24 02:21
not sure if that is exactly what you were looking for though

binhn
2017-01-24 02:22
and “chaintool new” with an option to launch an env and deploy the app

ghaskins
2017-01-24 02:22
ok, i see where you are going

ghaskins
2017-01-24 02:23
yeah, you could use chaintool code-generation capabilities to spit out whatever you wanted, and then drive an environment with docker-compose

ghaskins
2017-01-24 02:23
it would mostly be a function of defining the templates that we need

ghaskins
2017-01-24 02:24
chaintool is currently based on the stringtemplate engine (http://www.stringtemplate.org/)

binhn
2017-01-24 02:24
right and that is done with bdd features today, so we were thinking about capture that in an image, but it can definitely chaintool

ghaskins
2017-01-24 02:25
ok...i think regardless, moving towards integrating bdd with the $(DRUN) stuff makes sense

binhn
2017-01-24 02:27
agreed

binhn
2017-01-24 02:29
@ghaskins btw, we could use some feedback on this chaincode deployment proposal https://jira.hyperledger.org/browse/FAB-1783

ghaskins
2017-01-24 02:29
will take a look, thx

binhn
2017-01-24 02:30
thanks

lowry1515
2017-01-24 03:53
has joined #fabric-dev

kamo
2017-01-24 10:41
Hello, just a short question, is it possible to find out the ip address of the running membersrvc ?

arnaud
2017-01-24 11:02
@kamo, I don't know but ask on #fabric-ca where the experts are

kamo
2017-01-24 11:05
@arnaud I’m still using the v0.6 branch, so im not sure if #fabric-ca is the appropriate channcel, isnt it?

arnaud
2017-01-24 11:11
that's where all the experts in membersrvc are :slightly_smiling_face:

kamo
2017-01-24 11:24
okay thanks!

weeds
2017-01-24 11:29
@bmoss299 see just above on conversation with ghaskins please as this came in after our discussion and notes i posted up above

weeds
2017-01-24 11:30
@bmos299 see above

ghaskins
2017-01-24 11:55
is anyone aware of a way to see the chaincode stdout during deployment?

ghaskins
2017-01-24 12:22
or really any of the logging subsystems in general?

ghaskins
2017-01-24 12:22
I would like to see the 'dockercontroller" output, but not sure how to tune the level to debug

vadim
2017-01-24 13:02
has joined #fabric-dev

choojoyq
2017-01-24 13:14
has joined #fabric-dev

choojoyq
2017-01-24 13:16
Hello, is it appropriate channel for question about java chaincode deployment process?

arnaud
2017-01-24 13:30
@choojoyq you might want to try #java-chaincode

arnaud
2017-01-24 13:30
not that here is a bad place to ask, just that you may have better luck there

choojoyq
2017-01-24 13:52
@arnaud thanks for response, will try to find the answer there as well

choojoyq
2017-01-24 13:53
I have a module which provides common classes for my other modules, for example module 'common' and module 'm1' which depends on it. During chaincode deployment i point peer to the folder with 'm1' source code and build.gradle file. Sequence of steps that i noticed during deployment, correct me if i'm wrong : 1. Fabric starts new docker container. 2. Copies files from m1 directory to chaincode directory. 3. Runs grade clean & gradle build in this directory. So the issue is with step 3. Could you please explain why fabric required source code and build file during deployment instead for compiled archives(jar files for example)? This causes issue with referencing the 'common' module, cause i can't pass this directory during deployment and reference it using relative path, i can't reference it from maven local as well, cause docker container has its own m2 home directory which doesn't have this module(but i noticed that container knows about java-shim, i believe that this reference presents in docker image file). Is it possible to deploy chaincode using such project structure without using of remote maven repositories? i use fabric 0.6

weeds
2017-01-24 14:43
Scrum meeting started (late taking notes)- i'd like to continue to run BDD with current chaincode deployment.

weeds
2017-01-24 14:46
working on two things in JDK- (jim zhang)- have sdk load materials to initialize MSP for local and then need change a few things in TSA implementation; nothing on list are being checked off. we had discussion with Grant/Pat who are working on events. ARe you working with Jason on template stuff? The template is involved somewhere in the request. Jason said let's get together.

claytonsims
2017-01-24 14:50
keith was to start intermeidate ca

claytonsims
2017-01-24 14:50
thinks its quick

claytonsims
2017-01-24 14:51
moving to docs. binh says we have default template, jeff generate doc from bdd.

weeds
2017-01-24 14:51
ledger- beyond list- manish is doing some work on checking phantom reads

weeds
2017-01-24 14:51
JEff- i worry about hiding the complexity,,.. it is comforting to comprehend the steps to bootstram and start the network- it's less daunting

weeds
2017-01-24 14:52
We should not do policy at the orderer--

claytonsims
2017-01-24 14:52
don’t have anything to do with policy and order level

weeds
2017-01-24 14:52
we are using that same policy engine for escc.. it ends up being serialized as protobuf, so in process of documentation- there is not tons of options- group of them and or an or for policies

claytonsims
2017-01-24 14:52
meta data that drives a rule. group of them and and a or

weeds
2017-01-24 14:53
there is no language- it's a very simple -- we are not offering a language- it's an output with serialized structure containing protobuf that has ands, and ors,etc,..

weeds
2017-01-24 14:54
do we have the structure of the docs yet?

claytonsims
2017-01-24 14:56
nick will do playback on docs at 3 this afternoon

weeds
2017-01-24 14:56
nick needs some actual diagrams for the flow

claytonsims
2017-01-24 14:56
request to diagram for flow

claytonsims
2017-01-24 14:57
nick to get with sean on diagrams

weeds
2017-01-24 14:57
@sbarclay Nick needs help with diagrams for first version of documentation of version 1.0 that we deliver end of week

claytonsims
2017-01-24 14:57
barry (qa) talking about docker compose for 3 configs and channel

claytonsims
2017-01-24 14:59
should not use ordering chain

claytonsims
2017-01-24 15:00
ordering system chain id. was **chain_ID. got rid of **. for chain we bring up in beginning

claytonsims
2017-01-24 15:01
will not expose to peers will have guid.

claytonsims
2017-01-24 15:03
goals of alpha - channel and basics. may not be able to in sdk have other ways to create channel for alpha

claytonsims
2017-01-24 15:03
use cli to create and join

claytonsims
2017-01-24 15:04
can we drive cli from qa side?. ratnaker doing create and join via cli. gave SC scripts to create and join

claytonsims
2017-01-24 15:07
binh and script that use template - works. jz - want something every user can use. template has configuration items. orderer will supply template to sdk

claytonsims
2017-01-24 15:07
sdk is building by hand - close.

claytonsims
2017-01-24 15:11
tricky part is getting sdk material. solved my template? gari - only need public keys.. orgs have public root certs. jz - need way to persist materials w/o genearatign on the fly.

claytonsims
2017-01-24 15:11
gari - alpha won’t have doc with every config option documented

claytonsims
2017-01-24 15:13
gari - what can we show nest - solo, 3 peer, each peer separate org, fabric ca 1 msp that trusted. this would be useful for people. all we can by weds next week

claytonsims
2017-01-24 15:16
gari stressing simple. slight modification of what was delivered last week. preserve artificats from jeff, doc end user experience. then have updates after feedback from users

claytonsims
2017-01-24 15:18
jason - jeff creating real thing. need to strip down info for a template

claytonsims
2017-01-24 15:19
who is working java shim? murali says talk to wil

claytonsims
2017-01-24 15:19
jeff bdd self generated

claytonsims
2017-01-24 15:19
ca

troyronda
2017-01-24 15:55
@muralisr another question - when adding peers to an existing channel with an already instantiated CC on that channel, does the sysadmin need to call a start command for the CC or will the peer automatically start the CC? What about after calling Stop (without destroy)

troyronda
2017-01-24 15:55
(re: 1783)

gmuecke
2017-01-24 16:42
has joined #fabric-dev

muralisr
2017-01-24 16:55
@troyronda the current model is to let an invoke for the CC (in the context of a chain) to bring up the CC… having CC started as part of an invoke allows the “start” to be associated with a proposal (invoke proposal) automatically - and we don;t have to distinguish between start-on-instantiate vs restart-if-not-running. Do you think there’s a need for a separate Start ? `What about after calling Stop (without destroy)` yes, the “destroy” should be a flag IMO

ivan.sat
2017-01-24 16:58
has joined #fabric-dev

troyronda
2017-01-24 17:00
@muralisr was just curious on the proposal :slightly_smiling_face:.

muralisr
2017-01-24 17:19
@troyronda ah ok :slightly_smiling_face:

meraki
2017-01-24 17:52
has joined #fabric-dev

meraki
2017-01-24 17:57
Hi, How to run a peer without security setup? [v1.0]

meraki
2017-01-24 17:58
Is it a correct channel for this question?

ghaskins
2017-01-24 19:14
@meraki i think by default, most things come up with security disabled

ghaskins
2017-01-24 19:14
however, if you want to use an SDK client, they minimally require the CA to be available

ghaskins
2017-01-24 19:14
if you only want to drive via CLI, you can skip the CA

meraki
2017-01-24 19:16
Yes, I realized that. Thanks @ghaskins Posted the query with logs on the fabric channel and got my question answered.

ghaskins
2017-01-24 19:16
oh, ok, sorry for late response then

meraki
2017-01-24 19:16
I am just trying to deploy a chaincode by running the peer node locally.

alexz
2017-01-24 19:59
has joined #fabric-dev

nickmelis
2017-01-25 11:14
any hint on why I am getting this error when deploying java chaincode in non dev mode? ```vp0_1 | 11:08:54.470 [dockercontroller] deployImage -> ERRO 173 Error building images: API error (500): {"message":"Cannot locate specified Dockerfile: Dockerfile"}```

kamo
2017-01-25 13:19
Im trying to run the authorizable_counter example (v0.6 , Docker on mac), but by incrementing the counter i get the following error: Position => error Failed retrieving extension. Does anyone may know whats going wrong?


bmos299
2017-01-25 13:41
Please note chaincode tests now breaking due to the interface change. @ramesh hit this in his FIT (functional integration test) run. https://jira.hyperledger.org/browse/FAB-1835. ....I'm sure other chaincodes are broken too.

rickr
2017-01-25 13:57
@jyellick Are we reintroducing the need for ASN1 encoding with the latest commits ? It looks to me if I read the code updates its now being done with BlockHeader ?

jyellick
2017-01-25 14:08
@rickr Correct, the conclusion from the crypto team in #fabric-crypto was that this was the best way to get deterministic bytes to hash over for the block header

rickr
2017-01-25 14:11
This poses a burden on toolkits for have ASN1 encoding that we so far have avoided. Why not the protobuf encoding ? FYI @garisingh @jzhang

jyellick
2017-01-25 14:13
@rickr Protobuf encoding is not guaranteed to be deterministic

jyellick
2017-01-25 14:14
At a language level, to handle our certificate structure, ASN.1 is already required

rickr
2017-01-25 14:14
So far we've not needed for the toolkits

jyellick
2017-01-25 14:16
Understood. In addition to @garisingh tagging @elli @aso @adc as they were also involved in this decision

jzhang
2017-01-25 14:17
@jyellick @rickr @adc I’d like to understand this better, so protobuf is not deterministic in the marshal-unmarshal cycles

jyellick
2017-01-25 14:18
Unmarshaling is always deterministic

jyellick
2017-01-25 14:18
Marshaling is not

adc
2017-01-25 14:18
so, ASN.1 is generally used for cryptographic objects because it supposed to give minimal encoding and is deterministic. We know that it is not perfect but it is the de facto standard.

jyellick
2017-01-25 14:18
In practice, we have gotten away with using proto marshaling and depending on it to be deterministic, but there is an explicit disclaimer from the proto folks that it is not guaranteed.

rickr
2017-01-25 14:19
Ok -so lets scrub protobufs and do everything ASN1 .. :slightly_smiling_face:

jyellick
2017-01-25 14:20
This was pushed by @simon months ago, but, was decided we could not accomplish this in the timeframe we had

jyellick
2017-01-25 14:21
(Also, note that proto encoding/decoding is noticeably faster than ASN.1, my vague recollection from the benchmarking done a while ago was that it was over an order of magnitude faster)

rickr
2017-01-25 14:23
I'm failing to imagine how *ALL* of other encoding in protopufs is sufficient and for this single case we now need to use ASN.1

jyellick
2017-01-25 14:27
The messages have all been designed to tolerate the non-deterministic marshaling of protobuf. Note that there are many fields which are marshaled bytes. In many of these cases, it is so that the receiver can verify a signature or hash over the marshaled object before unpacking it.

jzhang
2017-01-25 14:28
Jason, that’s what i was getting at, as long as the signature is generated over a marshaled bytes and it’s verified before it’s unmarshaled, i think protobuf is fine

jzhang
2017-01-25 14:28
i’d like to know where this fails and would require ASN.1

jzhang
2017-01-25 14:29
not simply “it’s more deterministic"

jzhang
2017-01-25 14:29
@adc ^^^

jyellick
2017-01-25 14:29
@jzhang You're absolutely right, if the signature or hash is generated over marshaled bytes, and we have those marshaled bytes, it is sufficient.

jyellick
2017-01-25 14:31
In the block case, the header, and the block data, both have hashes and signatures. But they are proto messages, not marshaled bytes. If the block structure had the header as the marshaled bytes of a BlockHeader message, then we would be okay, but that is not the block structure today

jyellick
2017-01-25 14:34
@rickr @jzhang Out of curiosity, when does the client need to compute the block header hash? I'd have assumed the SDK does not maintain the hash chain, so I'm not sure of what value computing this hash would be?

weeds
2017-01-25 14:35
Ok Binh came by open area and a few people congregated---> Here are some notes as a result

jyellick
2017-01-25 14:35
Note that we also need to fix the hashing of the data block, which is targeted to be done as a Merkle tree, but again, unless someone is interested in maintaining the hash chain, I'm not sure what the value of computing this hash is.

weeds
2017-01-25 14:36
Chaincode Ednorsement policy did make it in- there is still another 1/2 to go

weeds
2017-01-25 14:36
For Chaincode REturn object - this one is in,.. and everyone needs to rebase- this is going to change your chain code... This guy is to return different status code on every chaincode

weeds
2017-01-25 14:37
Anchor peers is blocked because the peer needs the handler finished which Jason Yellick has pushed some of this-- If Jason's stuff is checked in, we can proceed

weeds
2017-01-25 14:38
All peers connect to the ordering service- you need to join the channel at bootstrap- that code has to be written, because not all peers will get the identity channel--> Jason Yellick owns this

jyellick
2017-01-25 14:39
@weeds I can hopefully get this done today.

jyellick
2017-01-25 14:39
(Am on the hangout, but cannot hear anything)

weeds
2017-01-25 14:39
We are almost done with the system chaincode refactoring which will come in this AM- Murali did that work

weeds
2017-01-25 14:39
Chaincode calling chaincode is almost 1/2 way there- Binh is debugging

weeds
2017-01-25 14:39
CLI channel to create default- barry is working on that relative to the docker image

weeds
2017-01-25 14:40
For ledger with Dave enyeart- there are change sets out for finishing couch miscelanous items and query.. we ahve questions on refactoring for chaincode API- he is going to get with Murali

weeds
2017-01-25 14:40
Change set on history of key values 9LEVEL DB) IS ALMOST READY (SORRY CAPS)

weeds
2017-01-25 14:41
the phantom read work done by Manish is readyy and checked in for review and has +1 reviews from David- needs Binh or Gari to review this.

weeds
2017-01-25 14:41
One of the issues is that everyone is so busy- noone is doing the reviews- we need help on this

weeds
2017-01-25 14:41
In terms of getting couch environment into docker for next week- Dave Enyeart talked to Barry - bmos299.. we left it that after you get simple happy path, we will add couch to docker compose.

rickr
2017-01-25 14:42
@jyellick I think we will eventually need to parse it to get the block number when monitoring what transactions have processed. The blocknumber will make sure we don't process this again

weeds
2017-01-25 14:42
For docker- we have basic path working, we are adding sdk.. Adnan is adding the couch stuff to it

weeds
2017-01-25 14:42
Barry is working with Adnan

jyellick
2017-01-25 14:43
rickr: You can certainly get the block number, but I'm not sure why you need to compute the header hash?

weeds
2017-01-25 14:43
On the finalized QSCC block tran structures- we talked about that yesterday. I sent a draft of whta we talked about and we will post in community on the channel- one of the questions was get transaction by id- we trun the tran protostructure, but header is above that, but header is importnat.. that is transaction id, time stamp.. so we may need to return the payload. it should be clear in the proposal for that... Dave Enyeart to post this to get feedback from community

weeds
2017-01-25 14:45
to ARtem- when we do state synch, are we calling same api to get block from one peer to send to another peer? they are using committer,.. but I think it does use same api.. we need to see if it's a lower level of apis that manipulates bytes... the lower level gets block by # and retunrs the unmarshalled block proto... that's what synch wants to do. maybe we have to optimize and suck the entire file over... Right now, it calls get block... that's very inefficient. We do a lot of marshalling and unmarshalling.. repeated. Dave is saying we need synch that works on serialized block then. Artem says ok. This is not for immecdiate, but needs to be logged in JIRA so as not to forget for optimization and performance (which is focus in February)

weeds
2017-01-25 14:47
On the SDK- there is outstanding chainset that needs to be approved. we're still making progress on event support and join chain. both are going in parallel. we are working on initializing the MSP that is needed to send create chain request to orderer. All is still on going. We are targetting event support completion if we don't get all chain creation and chain join-- is that ok? we will have to use CLI... that is the backup plan .. there is a lot of moving parts for chain creation, but we do want to get events support done. WE haven't added the references to ESCC or VSCC to deploy yet-- that is higher priority it seems like.. this is so application can execute.

weeds
2017-01-25 14:47
For event support- i merged chainset that Pat implemented

weeds
2017-01-25 14:50
What is ESCC /VSCC is needed? this is absolutely needed for endorsement. Has something changed? There are defaults being used.. there is an item that Murali has worked called chaincode lifecyle and endorsement policy. Currently transaciton comes in, we just say ok fine... but once we have endorsement policy which is mostly done- transaction must be signed by John. The work on the SDK side is adding a new field to the proposal , identifying ESCC and VSCC by name, which is really not significant,.. and we can add that support.. Policy being things like 3 out of 10 sigs... We can defiintely identify and add in there for policy or we can also default system for this round. Supposedly application should do preliminary checking on responses- if it's not meeting the policy- it should discard. Right now, we are just sending things over where VSCC will catch that. I'd like to keep that as is for end of month for alpha. Yes, sounds reasonable... we do think key to send in ESCC, VSCC, and policy. The CR that I talked about with endorsement policy is out there. it's called post it notation.. end/a/b something like that. you need signature for a and b... is that a string?

weeds
2017-01-25 14:50
from application, we haven't decided from community whether string goes all the way to the peer or deployment... or the SDK would proto this into structure- i suspect it's going to be at the peer for desing sake.

weeds
2017-01-25 14:50
CLI we can do this already

weeds
2017-01-25 14:51
Documentation- There is higher level pieces,.. maybe 7 or 8 separate higher level topics as an overview documentation for the community. 2 that are basically done and we can complete remainder in day or 2... and knock out the rest of the stuff with the various people assigned.

weeds
2017-01-25 14:53
The flow being talked about is what is fabric for,.. what is hyperledger community, what are definition of terms, what is architecture, how do you get the docker images up and running,.. and how do you pogram against chaincode. the hope is to have this and docker images to see what feedback we get in real time meeting next week.

weeds
2017-01-25 14:54
we need a sample, Question is what do we show for policy, MSP,etc,. and need some input from the community for this first round ... We do need to probably talk about system chaincode and the apis.. that has to probably come from Murali or Binh at this point. Performing a query against couchdb we do need to include for complex queries should come from Dave Eneyart

weeds
2017-01-25 14:56
When they do the docker compose for getting started- it will have example 2 chaincode.

weeds
2017-01-25 14:57
in text, you can create a channel, join a channel with these # of peers, there is a CA set up, here is your node sdk.. do an enroll and signing cert ,.. we provide a very basic nodejs program.. so at least people have some artifacts to give feedback on.

jyellick
2017-01-25 14:58
@adc

weeds
2017-01-25 14:58
we have docker images published somewhere, the docker compose that ties all together, and zip file with some generated materials in generated location so people can connect to it- this gives you network that works,.. another file that shows application code, mpm install and run... seems like maybe that will help get people get started next week?

weeds
2017-01-25 15:00
One thing in the YAML we should remove- the fields in security section need e removed -- all those really are not appropriate- that security seciton is getting removed-

weeds
2017-01-25 15:00
Chaincode interface chain really is a big bug-- that has to get updated

weeds
2017-01-25 15:00
someone could help that and rebase

adc
2017-01-25 15:06
okay, @jyellick @jzhang @rickr, what I want to say is that ASN.1 is preferable solution, I would say. We can avoid it if necessary. If we do, let's have it properly documented

jyellick
2017-01-25 15:16
@rickr @jzhang I'm still trying to understand why the SDK ever needs to compute this hash

weeds
2017-01-25 15:26
Binh had discussion with Elli and Angelo- I have a function called check acl,. This is the chaincode calling chaincode- before we set everything to invoke another chaincode specification, we check the acl.. and what that means is what we want to do is to check to see whether this transaction in proposal the signature is valid on this channel.. so imagine that chaincode 1 calling chaincode 2. chaincode 1 on channel 1, chaincode 2 on channel 2, chaincode 1 is invoked by user 1... so when proposal comes in, we verify the signature against that user 1 against the config block on channel 1... so now when chaincode 1 calls chaincode 2 on channel 2 passing along the proposal.. so now we have to verify again the user 1 signature against the channel 2 where chaincode 2 is on.. so this is what happens in check acl. but we seem in code to be missing a few pieces-

weeds
2017-01-25 15:28
there is check sig from creator- message validation go... it's a local function.. I think I can call this function, but this function- is that it's local, so we need to change to global. but the problem is this- it takes the information we only have from a side proposal, which is at this point is in the handler at this point.. the only thing we have is th eproposal, we don't have side proposal. I want to talk to someone who created this- Elli, angelo, ale? do we need all of this- can we work with proposal or side proposal to call this function? We can get message bytes is the side proposal is the proposal bytes itself...

weeds
2017-01-25 15:28
We either have to change our handler to pass the enitre proposal.. versus just the proposal given by this function.

weeds
2017-01-25 15:29
Is this happening on the same peer? you can assume that the proposal has already been verified, because it's verified in the first channel, so you don't have to verify anymore- if the peer is malicious- it's malicious.

weeds
2017-01-25 15:29
We have to assume the peer is doing the right thing- let's assume that this user has access to channel 1 to do something but this user does not have access to channel 2.. even though the peer joins both channels. So in this case you do need this.

weeds
2017-01-25 15:30
We do need to enforce the ACL on both channels-

weeds
2017-01-25 15:31
that function calls from validate proposal and check sig- creator is respect to this one chain.. is there a chain id on that? yes... we are assumin the creator verified on channel 1.. that same creator instance can be used... so yes.. if you have creator bytes you re fine.. so how do you check the read set and write set- how do you know? the read can be modified on a different channel. we don't do any of that except we verify tat the user signature is verifiable on channel 2.. we need to develop that (Angelo working on that)... ARe you saying you get read/write set of chain? what does read/write set on 2nd chain? how do we resolve version conflicts regardless of access control?

weeds
2017-01-25 15:32
If you read the JIRA item- it's a read only and and there is no read/write set for the called chaincode.

weeds
2017-01-25 15:33
if the query is on the same chain as chaincode- you have read/write set of the chainocde and verify vscc shcek . but on different channel, we can ONLY do read and query only

weeds
2017-01-25 15:33
there is no read set- we are not sending read set from chain 2 inside.. the only thing proposal response has is the read/write set is for the first call of the chain.

weeds
2017-01-25 15:34
WE do have the read/write set collected on the same channel and it's working-verified

weeds
2017-01-25 15:34
but on different channel we do not want to collect the read/write set on the 2nd channel- we only want to return the value.

weeds
2017-01-25 15:35
Now that you mention it- there is one more thing you need to do when doing different chains-- but same logic calling- it's going to try to include it and we need to fix that on the 2nd chain

weeds
2017-01-25 15:35
From security point of view- we can check the signature- yes?

weeds
2017-01-25 15:36
the 2nd chain code is working like an oracle.. it might be an endorser that might get a different value.. so you might see a transaction be rejected.. yes, sdk would reject. this has to be calirifed to the developer.. it depends on how you implement- if you go to oracle- give me the current value- because endorsers might end up with different view, but security of execution-- you do same process when proposal first came-- is the oracle value has to be included what the endorsers endorse- the read set... but not clear if this makes sense- it's up to the calling chaincode if they want to... because eventually the value is considered by calling another chainocde will effect the outcome of the execution of that chaincode

weeds
2017-01-25 15:37
if the value was idfferent, then the outcome is different,.. and the end result of that proposal would be different

weeds
2017-01-25 15:37
there is no difference if you even have a regular call outside the blockchain

weeds
2017-01-25 15:38
how do you replay the blockchain in this case?

weeds
2017-01-25 15:39
this would allow for non-determinism

weeds
2017-01-25 15:39
if 3 endorsers get the same response- it will have same simulation, endorsement will succeed and commitment will be validated despite the chaincode is not replayable

weeds
2017-01-25 15:44
you have endorsement- you send read/write set... you signed agreeing to set of inputs and you got outputs.

weeds
2017-01-25 15:44
proposal come in and you want to include external data- you need to put it into key... you have to do that.

weeds
2017-01-25 15:44
This is the same as keys we read without modifying

weeds
2017-01-25 15:44
the big point is this there are rules for writing chaincode

weeds
2017-01-25 15:44
1) access only state variables on database

weeds
2017-01-25 15:45
2) if you access something external and you are on your own and you better record it somehow

weeds
2017-01-25 15:45
This is true whether calling chaincode or calling external source

weeds
2017-01-25 15:45
@bmos299 please make sure in doc this is recorded clearly point 1 and 2 up above

sandra.vrtikapa
2017-01-25 15:48
has joined #fabric-dev

sandra.vrtikapa
2017-01-25 15:50
Currently I can only receive/access chaincode events via block events. If I set a chaincode event in user chaincode and that part of the code doesn't generate block event later on I am not able to receive my chaincode event. Is there a plan to support sending/firing chaincode events from user chaincode independent of block events?

ghaskins
2017-01-25 16:28
@pmullaney ^^^

pmullaney
2017-01-25 16:39
@sandra.vrtikapa : if you set a chaincode event in a chaincode, you will generate a block( or be included in a block)

pmullaney
2017-01-25 16:40
if you use the upcoming eventhub in the v1.0 api, you can just register for a chaincode event - eventhub takes care of parsing the chaincode event from the block it receives

pmullaney
2017-01-25 16:41
I hope that clears the question up if not ask away


sandra.vrtikapa
2017-01-25 17:01
@pmullaney I would like to be able to send chaincode event from user cc even if there is no commit.

pmullaney
2017-01-25 17:02
I don't think that is allowed as events are part of the ledger state

pmullaney
2017-01-25 17:03
you *could* potentially just send a message from your chaincode for that purpose

pmullaney
2017-01-25 17:50
one more comment, the only way to generate a chaincode event is to issue a transaction to the chaincode, so you will already be committing at least that transaction. Which happens to be the transaction that the chaincode event will be associated with

tzipih
2017-01-25 20:51
When running even just one peer and one order using docker-compose (using a docker-compose file inspired from bddtests/docker-compose-next-4.yml), a lot of weird text was displayed on the screen and deploy never finished.

tzipih
2017-01-25 20:52
We think the reason is that in the function `Sign` of `msp/identities.go`, in debug mode, the plaintext is displayed. And we guess during a deploy a very large plaintext is displayed.

tzipih
2017-01-25 20:53
The workaround was to increase the logging level to info, or more precisely, to remove the line `- CORE_LOGGING_LEVEL=DEBUG` in `compose-defaults.yml`. Since it worked.

tzipih
2017-01-25 20:54
By the way, what does the environment variable `DOCKER_NEXT` do?

markparz
2017-01-25 21:11

tzipih
2017-01-25 21:33
thank you we solved this

pvishnum
2017-01-25 22:03
has joined #fabric-dev

dayu
2017-01-25 23:55
has joined #fabric-dev

simon
2017-01-26 00:24
what's so bad about ASN.1? it's even part of any system that does crypto.

mbaizan
2017-01-26 11:10
has joined #fabric-dev

weeds
2017-01-26 14:34
Quick meeting here -

weeds
2017-01-26 14:34
Event is ready to be merged (Jim Zhang)

weeds
2017-01-26 14:36
Chaincode return object got done

weeds
2017-01-26 14:36
As far as SDK we are in good shape- we need to test in the environment with the docker images- that's crypto materials

weeds
2017-01-26 14:37
Rick needs one or two more days for Java to clean it up--- We are referring to the nodejs.sdk

weeds
2017-01-26 14:39
There is a remaining glitch somewhere - when i receive the block event and I realize my transactions is in there- if i send out invocation for the chaincode- right away "chaincode is not found" i have to ingest an artificial pause. the event producer may send things prematurely (not happening in Java,.. ) perhaps sending before commit?

weeds
2017-01-26 14:39
We are working on more event friendly api- we want it to be easier apis on chainclass itself-- other one is we continue to do the join- create channel and join channel which is parallel work

weeds
2017-01-26 14:40
We need to add endorsement policy to SDK-- Binh indicates that he reviewed on endorsement policy and some minor things need to be changed. ESCC/VSCC policy needs to be in as part of that)- the cr is out there now.. it's the same changeset from aAle.

weeds
2017-01-26 14:42
For Fabric CA- about to check in the intermediate CA support. the CLI simplification. It's under review and iterating on the review. Rest API doc is in sswagger now, REadme and read the docs is dependent on CLI simplification.

weeds
2017-01-26 14:43
Again, intermediate CA support should be in by end of day. We have one in review to add a bunch of new tests- it's actually pretty significant on test from Allen- these are scripts that Allen wrote.

weeds
2017-01-26 14:43
WE don't know how to run it and there is no instruction.

weeds
2017-01-26 14:44
@bmos299 see above- they need to be CI tests or they should be documented clearly on how to run

weeds
2017-01-26 14:44
These are unix scripts so they don't run on windows which is the issue

weeds
2017-01-26 14:45
There is a chainset from Jason- we have fix for the gossip, take a look at CR 4853

weeds
2017-01-26 14:46
@muralisr please take a look at 4853

weeds
2017-01-26 14:46
Gossip gets order endpoints from CB- this is being work today- i am testing end to end- i have finished the code and need to test before i push a CR.

weeds
2017-01-26 14:47
Anchor peers - config handler is what is odone from above that murali has to review

weeds
2017-01-26 14:47
Chaincode Endorsement policy from Ale has CR today

weeds
2017-01-26 14:48
SEcurity and gossip integration by Angel- we have missed 2 pieces update local MSP.. this comes from the system ledger... we miss the readers policy of the channel- the code is there, but we have these two pieces we need to complete

weeds
2017-01-26 14:48
TX proto shouldn't contain response- that has been done

weeds
2017-01-26 14:49
For chaincode life-cycle- Murali indicated he plans to work this full time on deploy/init/upgrade and policy

weeds
2017-01-26 14:49
System chaincode refactor (location) has been Murali-- the CR is in and merged

weeds
2017-01-26 14:49
Chaincode calling chaincode- Binh is struggling with some bugs..

weeds
2017-01-26 14:50
he's doing this for query.

weeds
2017-01-26 14:53
What i learned debugging the query for chaincode calling chaincode- serviceability is good- the log for debugging is pretty good... but there are a couple of things, when we log- we need to log the right information... but it does not give me the information that I need. i had to change log statements.. sometimes i encounter statements that are 100's of pages... When you log something- we really have to have a strategy.. log enough to give information so we can determine the cause of the problem.. try to avoid not to log that many pages, especially these happen in every single transaction- imagine if someone is running 1000's of transaction a second- they won't be able to handle this. We also need to walk through and make sure that the payload is not in the log and we need to step through and analyze to protect everything--- given the security element. This is a reminder to people and we will do analysis at all points through our security team to check for all these gaps.

weeds
2017-01-26 14:53
Please remember to use the new logging framework.

weeds
2017-01-26 14:54
IN SDK side- you can use for info- we put in console, in debug, we put in file.. customers can control that. and we need that for the backend.

weeds
2017-01-26 14:54
hashes also can not be written either!

weeds
2017-01-26 14:55
Ledger- we have changesets that need reviews for finish couch misc item, query exposed to app chaincode, history of key values (level db)- add to qscc, expose to app chaincode... and phantom read management-- CRs are already there

weeds
2017-01-26 14:55
@muralisr need you to review please

weeds
2017-01-26 14:55
We are working to have the chaincode examples for next week

weeds
2017-01-26 14:55
We did get our plans straight for QSCC - and will do the tran level and include the header information

weeds
2017-01-26 14:56
SDK can use the system level chaincode-- but we also expose to regular chaincode (ie to application chaincode)

weeds
2017-01-26 14:56
Documentation- Nick and Josh are putting topics to gerit- there are top 4 there that are done- High level, technical overview/glossary, remove 0.6 material , docker compose and 3 configuration--> CRs are out there

weeds
2017-01-26 14:57
Josh working on higher leevel stuff and Nick is getting started content-

weeds
2017-01-26 14:57
WE took out the 0.6 stuff and left common stuff,.. and we are starting new for topics for the hackathon

weeds
2017-01-26 14:57
There is some question as to whether that should go public on the read the docs build on Tuesday or not?

weeds
2017-01-26 14:57
Have you figured out how to do versioning in read the docs?

weeds
2017-01-26 14:57
if we have in repo in github-

weeds
2017-01-26 14:57
readdocs you can select 0.6 or latest

weeds
2017-01-26 14:58
we have that capability- for the latest we should call it version 1.0 alpha-- latest is current tag they get it

adc
2017-01-26 15:09
@binhn @garisingh @tuand @elli @aso and all, It might be useful to start a discussion to understand if logging transaction data might cause confidentiality issues. Do you think it is an issue?

jzhang
2017-01-26 15:51
@aso I opened a bug that needs to be addressed asap for the alpha: https://jira.hyperledger.org/browse/FAB-1862, @muralisr is suggesting for him and you to investigate

binhn
2017-01-26 15:52
i think we need understand the data object that we are logging not to inadvertently disclosing confidentiality

jzhang
2017-01-26 15:53
@garisingh and I did some preliminary investigating and we both believe the producer sent event too early. instead of sending it from the deliver service client, while the block goes through gossip service, it should be sent after the committer has committed it, like https://github.com/hyperledger/fabric/blob/master/core/committer/committer_impl.go#L60

mgutala
2017-01-26 15:54
I am trying to build latest fabric in vagrant env. fabric bild fails here

mgutala
2017-01-26 15:54
docker tag hyperledger/fabric-javaenv hyperledger/fabric-javaenv:x86_64-0.7.0-snapshot-f73825f build/bin/peer CGO_CFLAGS=" " GOBIN=/opt/gopath/src/github.com/hyperledger/fabric/build/bin go install -ldflags "-X http://github.com/hyperledger/fabric/common/metadata.Version=0.7.0-snapshot-f73825f" http://github.com/hyperledger/fabric/peer core/chaincode/ccproviderimpl.go:20:2: cannot find package "context" in any of: /opt/gopath/src/github.com/hyperledger/fabric/vendor/context (vendor tree) /opt/go/src/context (from $GOROOT) /opt/gopath/src/context (from $GOPATH) make: *** [build/bin/peer] Error 1 rm build/image/javaenv/Dockerfile build/image/ccenv/Dockerfile

mgutala
2017-01-26 15:54
Any ideas ?

aso
2017-01-26 15:58
@jzhang thx Jim, will look into it asap

adc
2017-01-26 16:04
@binhn, for example a signature verification method that wants to debug the message against which the signature is verified, does not have any means to understand if the data is confidential or not. The request from signature verification comes from multiple places.

bur
2017-01-26 16:15
has joined #fabric-dev

tuand
2017-01-26 16:31
@adc, would it be enough to log only the digest and the signature ? admittedly, I'm a crypto newbie

adc
2017-01-26 16:34
the digest might leak information if the message does not have enough entropy. One can use the digest to brute force over messages to see which one matches the digest

kletkeman
2017-01-26 17:04
has joined #fabric-dev

tzipih
2017-01-26 17:59
Hi I am running a program that includes one peer and one order using docker-compose (using a docker-compose file inspired from bddtests/docker-compose-next-4.yml),

tzipih
2017-01-26 18:00
with chaincode_example02 from a second terminal

tzipih
2017-01-26 18:00
deploying/invoking the first peer works correctly now

tzipih
2017-01-26 18:01
but deploying the second peer returns an error "Error: Error endorsing chaincode: rpc error: code = 13 desc = transport is closing"

tzipih
2017-01-26 18:02
any suggestions as to how to solve this? Or can you perhaps point me to code/example that works with two peers? thx

arnaud
2017-01-26 18:04
@mgutala unfortunately vagrant is no longer used by most of the developers it seems and as a result it always takes a bit of work to get the build

binhn
2017-01-26 18:08
@mgutala when was the last type you re built your vagrant; there’s some changes a few weeks ago that require vagrant destroy/up

binhn
2017-01-26 18:08
@tzipih are you on 0.6 or 1.0 (current master branch) ?

mgutala
2017-01-26 18:09
I am on 1.0

mgutala
2017-01-26 18:09
I did a vagrant reload

mgutala
2017-01-26 18:09
should I destroy and recreate it ?

mgutala
2017-01-26 18:09
and on latest master branch

arnaud
2017-01-26 18:10
If you can afford the time it takes it is always worth trying when the rest fails

binhn
2017-01-26 18:14
@mgutala i would suggest you take a look at the multichannel setup docker file https://github.com/hyperledger/fabric/blob/master/docs/channel-setup.md


binhn
2017-01-26 18:16
if you haven’t done vagrant destroy this year, i would suggest do that

mgutala
2017-01-26 18:19
I will try that. Thanks

arnaud
2017-01-26 18:42
so, what's the equivalent of 'peer network list' in 1.0?

arnaud
2017-01-26 18:42
@binhn ?

binhn
2017-01-26 18:49
not equivalent but only a subset of gossip group that a peer knows about

binhn
2017-01-26 18:50
ie no master list of all peers

arnaud
2017-01-26 18:59
and how do I get that?

binhn
2017-01-26 19:18
we don’t have an api yet for that; the structure is in the fabric/gossip if you want to look and provide some admin grpc api

yacovm
2017-01-26 19:21
@binhn , what is the question?

binhn
2017-01-26 19:22
`what's the equivalent of 'peer network list' in 1.0?`

tzipih
2017-01-26 20:01
solved this error - had a issue with the ports - thx

tzipih
2017-01-26 20:19
@binhn I am working with fabric 1.0

tzipih
2017-01-26 20:19
I need to set up multiple endorserers

kostas
2017-01-26 20:28
Who in here has a hard-coded reference in their packages for `test_chainid`? (Or any hard-coded channel name that includes an underscore for that matter.)

kostas
2017-01-26 20:28
Besides the `orderer` package.

kostas
2017-01-26 20:29
^^ @jzhang @muralisr

kostas
2017-01-26 20:31
A heads up that I'll need to enable a filter that enforces certain restrictions on the allowed channel names. This is enforced by what's allowed in Kafka. As a result, underscores in names will be a no go, so please edit your dependencies accordingly.

kostas
2017-01-26 20:31
(Kafka does allow underscores in general, but it doesn't allow `hello_world` and `hello.world` at the same time, so we'll remove support for underscores to keep things simple.)

kostas
2017-01-26 20:34
Not sure our test coverage across the project is good enough to capture any breaks that this change will incur. (And it doesn't help that these hard-coded strings are not consistent from a quick grepping.)

kostas
2017-01-26 20:34
So, I'll do my best to test in advance, and I'll tag you (or whomever else you suggest) in that changeset, but still --

kostas
2017-01-26 20:35
I would suggest being proactive and switching to default channel names that do not have underscores in your code/examples.

tzipih
2017-01-26 20:43
it is working better now. thx.

jzhang
2017-01-26 20:47
@kostas yes we have `test_chainid` in all our test cases, but that can be easily updated. for chain names, do you have the rules documented somewhere that we can reference? would like to do client-side enforcement before it gets sent out

kostas
2017-01-26 21:06
@jzhang Here's a snippet from the code:

kostas
2017-01-26 21:06
```// ChannelNameRule rejects incoming chain-creation messages whose proposed // chainID (i.e. channel name) does not comply with the following restrictions: // 1. Contains only any of the following characters: // a-z (lowercase alphabetical) // A-Z (uppercase alphabetical) // 0-9 (numerical) // . (dot) // - (dash) // 2. Is shorter than 250 characters. // 3. Is not "." or "..". // // Our hand here is forced by: // https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/common/Topic.scala#L29```

kostas
2017-01-26 21:06
We'll have to note these down in a Markdown document as well.

cyrax
2017-01-27 00:11
has joined #fabric-dev

archivebot
2017-01-27 04:00
has joined #fabric-dev

dinesh_rivankar
2017-01-27 04:56
What is the maximum lifetime for the certificates in ver 0.6 ?

yacovm
2017-01-27 04:56
@dinesh_rivankar , ask in #fabric-crypto

weeds
2017-01-27 14:37
Quick meeting here- longer term when someone goes to get started- they don't have to clone the repo... but for the hackathon and short term- we tell them to get clone in the repo

weeds
2017-01-27 14:37
You have to run from the root of the project- it's not goingn to be quite the same if you devlop application if you use the MPM- that could be odd

weeds
2017-01-27 14:38
what is the downside making the updates after we publish the MPM-- WE can do that... we just weren't sure as we thought you had blockers... Yeah- we can clean this up Monday. The preferable approach is to include it

weeds
2017-01-27 14:38
(IE we are talking about SDK)

weeds
2017-01-27 14:39
WE will still go with that- Jim Zhang and Ratnakar are going to publish it today-- We are going to bake the chaincode in the cli in the images also... for one environment- they don't have to type get clone

weeds
2017-01-27 14:39
We don't want to do get clone for real users of the fabric-- get clone will be fall back

weeds
2017-01-27 14:40
SDK- What is update here? The last thing we want to do is publish to MPM that requires naming changes.. fabric-ca-client

weeds
2017-01-27 14:40
WE did not have the pending change that would be hard to move after the change- so I was waiting- that particular change is more work so we are going to push after the alpha. so I'm going to do the name change today.

weeds
2017-01-27 14:41
The ESCC/VSCC/policy is still a CR

weeds
2017-01-27 14:41
update CR return object has been completed

weeds
2017-01-27 14:41
The only thing we need to do is name change and publish MPM for alpha

weeds
2017-01-27 14:42
For the core:

weeds
2017-01-27 14:42
are we trying to get channel leader in? There is two cr's that is needing reviewed.. one has +2.. but we need to review the second one- and we need to connect delivery and client once this piece is in... These are under Yacov's name

weeds
2017-01-27 14:42
we need to get these in and complete review

weeds
2017-01-27 14:43
For gossip get order endpoints from CB- we completed this - we need someone reviewed

weeds
2017-01-27 14:44
HSM is committed into master branch- a couple of other people it broke some of the rocks db library.. and could not compile against the master... The CI had some dependency in the past--- Ry mentioned sometime on slack- the images on CI are not images we use in vagrant- maybe that's the reason. Jonathan said he is able to compile, but Greg is not able to compile. Murali is using the latest.. maybe vagrant has rocks db from long ago- Murali said he destroyed last week... He's going to recreate today to see

weeds
2017-01-27 14:45
Murali is trying right now- we need to resolve that right away- Binh knows he himself has to rebase.

weeds
2017-01-27 14:45
Gari said---I just build on the MAC and had no problems

weeds
2017-01-27 14:46
there is some wierd mix up in vagrant i think

weeds
2017-01-27 14:47
Somebody said that they saw it on slack.. but I don't remember what the actual issue was- maybe they were running a different version of vagrant or base environment... Make peer still seems to build and runs in docker- were you building in vagrant? the only thing is c go flag that was set? Maybe it's in the base image, I'll look.

weeds
2017-01-27 14:47
Typically i destroyed- make peer whenever I can- so far Murali has not had problems and will check it for certain.

weeds
2017-01-27 14:47
Murali wants to get chaincode lifecycle in next week- deploy/init/upgrade- and to do it seperately

weeds
2017-01-27 14:48
CC calling CC (query)- it is working Binh says though it's occasionally hanging and still debugging

weeds
2017-01-27 14:49
We did not get the CR's for the ledger in- need + 2 to happen

weeds
2017-01-27 14:49
that covers items we talked about yesterday

weeds
2017-01-27 14:49
Problem is the # of lines of code- we need to stop doing this- it's too hard for community to consume

weeds
2017-01-27 14:50
Dave acknowledged that they will work on that

weeds
2017-01-27 14:50
For fabric- CA-......... readthedocs has a CR

weeds
2017-01-27 14:50
CLI simplification has several submitted,.. keith has 2 more that will be submitted today

weeds
2017-01-27 14:50
We need Maintainers to help over the weekend please

weeds
2017-01-27 14:51
Gari, Chris, Jonathan and folks from other all the other companies we need help with review.

weeds
2017-01-27 14:51
Sharon to ask for that request on maintainer list

weeds
2017-01-27 14:51
TCERt stuff is also still for CR

weeds
2017-01-27 14:51
Vlad is on vacation next week, so he gave a dump of the status.

weeds
2017-01-27 14:52
WE don't need HSM in the alpha at this point

weeds
2017-01-27 14:53
For documentation- we need help to review these

yacovm
2017-01-27 14:53
https://hyperledgerproject.slack.com/archives/fabric-dev/p1485528169001989 Just a correction- I reviewed them... they are not my commits.

weeds
2017-01-27 14:53
Josh is getting some +2's with Chris and getting some help- he knows there is urgency as he gets through review

weeds
2017-01-27 14:53
there are a couple of topics to push today-- i checked with Nick- he's in good shape, no blockers. he's doing the specifics- getting started specific steps. getting docker going,etc,.. he has no blockers on that

weeds
2017-01-27 14:54
More people who are able to look at it and read in detail the better

weeds
2017-01-27 14:54
It does not have to be maintainers- we should ask the OM folks -

weeds
2017-01-27 14:54
Quick question- how are we going to cut and tag the alpha

weeds
2017-01-27 14:55
When are we going to do this- the end of today is an attempt to cut it

weeds
2017-01-27 14:55
We will run through the process and see how it works- we will test this weekend-

weeds
2017-01-27 14:55
We will do again on Monday- and if better- we will switch.

weeds
2017-01-27 14:55
We need to do the same for the SDK branch- that has to go through Ry- right?

weeds
2017-01-27 14:56
I remember coordinating with Ry- i need to run something else from Greg. There is a process. @cbf will need to help Binh on how this works again

weeds
2017-01-27 15:01
@ry We have just realized we want to open a meeting, but we don't have great "community" collaboration tools outside of googlehangout to bring people from the channels

weeds
2017-01-27 15:01
because it limits how many people- maybe you guys can recommend something comin gforward

weeds
2017-01-27 15:01
(again sorry about any spelling errors)

weeds
2017-01-27 15:04
Dave Enyeart destroyed vagrant - started from scratch- and it worked.

weeds
2017-01-27 15:04
You have to remove the image--- this may be why there is an issue

weeds
2017-01-27 15:18
Jeff/Murali met and talked about how to break up the lifecycle chaincode and do it properly- the idea is according to Jira- we are going to take the deploy and spit it up into 2 parts - install/instantiate. it used to be that deploy put the chaincode on the ledger on all the peers on the channel, but now the install- you hvae to go on peer to install this chaincode- you have to do that on all the peers. the instantiate is very close to the deploy in that if the chaincode is there on the peer where you are trying to instantiate the chain code- it will find the chaincode and make sure it's valid chaincode- what does valid really mean? it will find the chaincode and do what deploy does before- run it on the chain and instantiate the variables on the particular channel.. just emphasize on the peer where you are trying to instantiate- you have that chaincode installed previously. At a high level, the install is local command- it's not a proposal.. it's just a local command where you install, but the instantiate is a regular proposal like it used to be.. So the real challenge is to make sure when you do the instnatiate, the mechanics are not difficult, the real important thing is that th eintegrity of the instantiate- is it the right chaincode- is the guy installing this the right guy? has the chaincode been tampered with?

weeds
2017-01-27 15:19
one instantiate has happened on the peer- then all the other peers -do get the state for chaincode, but those other peers that have the chaincode installed on system will be able to do invokes and queries- in 0.6,.. when we do a deploy I have to provide chaincode and the chaincode will live on ledger and will give all security- but when you separate it and you say leave locally and instantiate , we *have* to make sure the security concerns are properly addressed

weeds
2017-01-27 15:20
Peer 1 (p1) has chaincode installed locally

weeds
2017-01-27 15:20
p2 has chaincode locally

weeds
2017-01-27 15:20
(someone ran command to install it on that particular system)

weeds
2017-01-27 15:21
it's putting files there is install

weeds
2017-01-27 15:21
peer 3 does NOT have chaincode

weeds
2017-01-27 15:22
Now i'm in the SDK and I use the proposal mechanism to instanatiate - I will say the name of chaincode is "mycc", "zero version" these are the two parameters- these identify the chaincode- when I install chaincode- i'm not talking about any channel, that's the whole point.

weeds
2017-01-27 15:22
proposal (instantiate, "chanel 1, mycc, zeroversion)

weeds
2017-01-27 15:23
this is directed to lifecycle system chaincode - lccc

weeds
2017-01-27 15:23
proposal (lccc,instantiate, "chanel 1, mycc, zeroversion)

weeds
2017-01-27 15:24
proposal (lccc,instantiate, "chanel 1, mycc, zeroversion, initiate arguments)

weeds
2017-01-27 15:25
Don't worry about security just yet- proposal gets endorsed and sends to p1, p2 who have chaincode

weeds
2017-01-27 15:25
everything goes well,,.. init gets called, intialization, read/write set works and it becomes a transaction and the ledger

weeds
2017-01-27 15:25
Would it make sense to leverage a single channel-- and we can use ledger,.. and orders sign it and you have proof...

weeds
2017-01-27 15:26
whenever we talk, we should say org as well as it's important point

weeds
2017-01-27 15:26
SDK has to check on P1 and P2 is the same and it should be able to check it- what you did for deploy- you will have to do for instnatiate...

weeds
2017-01-27 15:27
in end you get ledger 1-> state a,... ledger 2-- state a

weeds
2017-01-27 15:27
what's my guarantee from app that P1 and P2 is the same? yes, we have to ask integrity of chaincode.. that's the next step

weeds
2017-01-27 15:27
the very first thing is the lifecycle system chaincode (LCCC) has name, version, hashcode

weeds
2017-01-27 15:28
when I instantiate-- and everything works correctly- in the end- 1) lccc gets entry on all the peers

weeds
2017-01-27 15:28
mycc , zeroversion,haschode

weeds
2017-01-27 15:28
Has something changed? check haschode and look at entry-- that's not sufficient, but it's necessary

weeds
2017-01-27 15:29
at least chaincode matches that's the very first thing

weeds
2017-01-27 15:29
Is there really ability to prove that the orgin of the hash really came from P2 or a different source?

weeds
2017-01-27 15:30
It is a valid question-

weeds
2017-01-27 15:30
what if someone put something and snuck in-- one thing I'm going to rely on is hash code is same... is that sufficient?

weeds
2017-01-27 15:31
Angelo- if p2 is malicious- it's exactly the same hash- but he can always run a different chaincode. if you want to protect against these attacks-- there are other mechanisms that we do here

weeds
2017-01-27 15:31
that we've implemented

weeds
2017-01-27 15:31
whatever the result comes back- if that satisfies the endorsement policy- that is what we care about on transaction

weeds
2017-01-27 15:31
whether the execution is different is now an administrative responsibility

weeds
2017-01-27 15:31
if the hash is included in blockchain- endorser did not do it's job properly by inspecting the transaction

weeds
2017-01-27 15:32
1) proposal- does the client need to specify the hash of code there? because it might force the peers to endorse a specific hash code-- and we put our signature on this specific hash-

weeds
2017-01-27 15:33
let's see if this make sense- we talk about chaincode being in p1- there is actually a package- it contains chaincode bytes,name version, and other things... my hash is a cobmination of all these things

weeds
2017-01-27 15:33
why don't we use a version - the hash of the chaincode- that will bind the sig of the endorser to a specific chaincode- that way they can say we did not instnatiate another chaincode-

weeds
2017-01-27 15:33
hashcode is 16 bytes--

weeds
2017-01-27 15:34
256 bits so 16 bytes

weeds
2017-01-27 15:34
the version you are uniquely idnetified

phoolet
2017-01-27 15:34
Hi

weeds
2017-01-27 15:35
asked clayton to take over

weeds
2017-01-27 15:35
as i had to walk away from Binh/Murali talking with angelo

claytonsims
2017-01-27 15:36
discussing need to put hash on proposal

hoolet
2017-01-27 15:36
has joined #fabric-dev

hoolet
2017-01-27 15:36
hi

claytonsims
2017-01-27 15:36
later on the ledger hash is signed by endorser

hoolet
2017-01-27 15:38
help I can't find json and json for logout. I am doing the chaincode examples

claytonsims
2017-01-27 15:38
when you instaniate 2 cc lccc and cc

hoolet
2017-01-27 15:38
json and url

claytonsims
2017-01-27 15:38
client sdk already check rw sets

claytonsims
2017-01-27 15:40
hoolet fyi i am streaming the notes for ad hoc meeting. in order to capture and share with the larger community.

hoolet
2017-01-27 15:41
ok, tkx

claytonsims
2017-01-27 15:44
what are good terms for this other than install and instaniate. jz suggest we use term deploy instead of instantiate. jz sdk point of view this is all deploy. install is just putting files down. murall - 2 policites involved, time of instaniate, channel create establishs who can adminstirate cc. second item. can this cc be instaniated on this specfic cc

claytonsims
2017-01-27 15:49
can we leverage serialized policy in the package to determine this. can we decide this is ok. important to answer. who can sign package. assume yes for now and can determine who and what chains. can this person admin have right to install cc and can this admin install THIS ccc

claytonsims
2017-01-27 15:50
murali now walking through example/scenario with team.

claytonsims
2017-01-27 15:58
talking through potential attack. attacker has broken into system. block box access. p3 should not be able to fool p1. get in place the basic attacks now and then come back to more edge case attack scenarios. elli - who is can install cc. jeff suggesting concept of a deployment channel. this might simplify is we do this.

claytonsims
2017-01-27 18:59
stepped away for customer call at 11:00 est. here is a quick summary of notes from marali to complete the thread

claytonsims
2017-01-27 19:01
for now we will agree to focus on core security aspects in new deployment model revisit complex corner cases later once we have some basic impleenation

claytonsims
2017-01-27 19:01
might be able to leverage bc deployment as opposed filebased per peer deploy

claytonsims
2017-01-27 19:01
i.e jeff’s propal

jzhang
2017-01-27 19:11
@ry @cbf I need to create a branch of fabric-sdk-node for the alpha release, I believe @binhn and @keithsmith are doing the same for fabric and fabric-ca

jzhang
2017-01-27 19:11
how do we go about doing this?

jzhang
2017-01-27 19:24
need to start with a common name

jzhang
2017-01-27 19:24
for the branch

arnaud
2017-01-27 19:25
@jzhang I think that's something you need to take to the #fabric-maintainers channel

jzhang
2017-01-27 19:25
ah makes sense, will do, thanks Arnaud

arnaud
2017-01-27 19:25
yw

garisingh
2017-01-27 19:26
1.0.0-alpha (at least as a tag) :wink:

garisingh
2017-01-27 19:26
Docker does stuff like 1.0.0-rc1 (which would be more like a set of betas)

weeds
2017-01-27 20:00
do you have the number for the 3pm?

ghaskins
2017-01-27 20:00
@garisingh ping

ghaskins
2017-01-27 20:50
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F3WUPPA6M/-.diff and commented: If you apply this patch

ghaskins
2017-01-27 20:50
@ghaskins uploaded a file: https://hyperledgerproject.slack.com/files/ghaskins/F3XMK05N0/-.sh and commented: You will see this crash from the peer

ghaskins
2017-01-27 20:51
This is what is causing the UT failures in mainline related to "linking to vp_1" or whatever the message is @sanchezl @harrijk

harrijk
2017-01-27 20:52
I think this might be the issue...

ghaskins
2017-01-27 20:52
my guess is someone committed a protobuf change recently, but still need to check

harrijk
2017-01-27 20:52
CULPRIT commit 51fecbad8dba58aa65faf7c04ac3ecbc708c63f3 Merge: 6a90017 2c98262 Author: Gari Singh <gari.r.singh@gmail.com> Date: Fri Jan 27 19:08:40 2017 +0000 Merge "[FAB-1762] Refactor couchdb history db to leveldb."

harrijk
2017-01-27 20:52
If I checkout the commit prior to the one above, there are no issues.

harrijk
2017-01-27 20:52
I'll re-run to confirm

ghaskins
2017-01-27 20:55
which maps to this, i believe https://gerrit.hyperledger.org/r/#/c/4725/

sanchezl
2017-01-27 20:55
After `make protos`, I see: ` modified: orderer/sbft/simplebft/simplebft.pb.go`

ghaskins
2017-01-27 20:55
ill try reverting

ghaskins
2017-01-27 20:55
@sanchezl does it run after that?

sanchezl
2017-01-27 20:55
trying...

ghaskins
2017-01-27 20:55
ok

ghaskins
2017-01-27 20:56
@ramesh can you explore ways in which we can log the unit-test/docker-compose.yml -> vp_1 to a file rather than /dev/null

ghaskins
2017-01-27 20:56
?

ghaskins
2017-01-27 20:57
if that fails, I would say the more conservative thing is to just let the peer be chatty

harrijk
2017-01-27 20:57
This is where it starts working: git checkout 6a90017a4dc147af205c907e154da3f3f584b82b

harrijk
2017-01-27 20:57
For me anyway.

ghaskins
2017-01-27 20:58
@harrijk that jives with all the data I have as well

ghaskins
2017-01-27 20:58
lets see what the result is from @sanchezl 's experiement

harrijk
2017-01-27 20:58
OK

ghaskins
2017-01-27 20:58
then we can decide if I should revert it or not

ghaskins
2017-01-27 20:59
@dave.enyeart ^^^^

sanchezl
2017-01-27 20:59
1st attempt failed with exact same error. I’m trying again, after a `make clean` but having trouble building.

ghaskins
2017-01-27 20:59
fyi, we might have to revert CR4725 @garisingh

dave.enyeart
2017-01-27 21:00
ok, i’m looking

garisingh
2017-01-27 21:05
what fails?

sanchezl
2017-01-27 21:06
@ghaskins , Updated generated proto did not help

harrijk
2017-01-27 21:07
There may be more than one issue here

harrijk
2017-01-27 21:08
Currently, the peer container startup ends in errors when issuing `make unit-test`

garisingh
2017-01-27 21:08
how is that possible when CI actually runs that?

harrijk
2017-01-27 21:08
CI is failing

garisingh
2017-01-27 21:09

harrijk
2017-01-27 21:09
I have no explanation as to why it passed during the CR verify.

harrijk
2017-01-27 21:10
When I look at current fabric verify jobs, there are a number of failures going on related to the peer container not starting up due to errors for the unit testing.

dave.enyeart
2017-01-27 21:12
in core.yaml, you can disable history by setting historyDatabase to false

dave.enyeart
2017-01-27 21:12
that may get you going while i troubleshoot

muralisr
2017-01-27 21:13
that seems to do it @dave.enyeart …just tested

muralisr
2017-01-27 21:14
we really need to get bdd or simple end-to-end integ test of some sort in

ramesh
2017-01-27 21:17
@ghaskins sure will check this..

ghaskins
2017-01-27 21:18
all: to debug, delete L3 from unit-test/docker-compose

ghaskins
2017-01-27 21:18
it will enable the peer log

ghaskins
2017-01-27 21:18
I did confirm that reverting 2c9826297a9131654a1625bfd49888645d7c748b fixes the issue

ghaskins
2017-01-27 21:19
I suggest I fire this in as a CR so we have it as a ready-to-go option, and then we can give @dave.enyeart some amount of time to derive an alternate solution

garisingh
2017-01-27 21:19
fire what in? disable to setting or revert the change?

ghaskins
2017-01-27 21:19
revert of 2c9826297a9131654a1625bfd49888645d7c748b

ghaskins
2017-01-27 21:20
it appears to be 100% reproducible with, and 100% successful without

garisingh
2017-01-27 21:20
and that's 4725?

ghaskins
2017-01-27 21:20
correct

dave.enyeart
2017-01-27 21:21
how about a change to core.yaml to set historyDatabase to false, to make the eventual fix smaller?

garisingh
2017-01-27 21:21
@ghaskins - you know how to revert a change with gerrit?

ghaskins
2017-01-27 21:21
@garisingh my experience doing it with the UI has been mixed

ghaskins
2017-01-27 21:21
I do it old-school

muralisr
2017-01-27 21:21
@dave.enyeart suggestion maybe necessary

ghaskins
2017-01-27 21:21
"git revert" and then create a new CR

garisingh
2017-01-27 21:22
ok - UI was failing so that makes sense

muralisr
2017-01-27 21:22
depending on where 4725 falls

ghaskins
2017-01-27 21:22
yeah, that was my experience

ry
2017-01-27 21:22
`git revert ...; git commit --amend -s; git push ...`

ghaskins
2017-01-27 21:22
actually, i never have seen it work, and I dont really trust it

ghaskins
2017-01-27 21:22
(i.e. is that unilateral power?, etc)

ghaskins
2017-01-27 21:22
heh

ghaskins
2017-01-27 21:23
@ry: yep, exactly

ghaskins
2017-01-27 21:23
tried and true, works like a champ

ry
2017-01-27 21:23
also if reverting multiple commits be sure to sign each one before doing the next

ghaskins
2017-01-27 21:23
understood, but in this case it seems to be just one patch

ry
2017-01-27 21:24
sorry I'm on autopilot eating bbq with my laptop out :slightly_smiling_face:

ghaskins
2017-01-27 21:24
not at all, i appreciate the guidance

muralisr
2017-01-27 21:24
@ghaskins @garisingh ..a consideration, … if we do `change to core.yaml to set historyDatabase to false` as the default could also be a solution

muralisr
2017-01-27 21:24
basically get the latest...

dave.enyeart
2017-01-27 21:26
here is the CR to set historyDatabase to false:

dave.enyeart
2017-01-27 21:26

ghaskins
2017-01-27 21:27

ghaskins
2017-01-27 21:29
@muralisr yep, im in favor of whatever works with the least disruption

ghaskins
2017-01-27 21:29
just wanted to queue a revert so the CI pipeline is primed

dave.enyeart
2017-01-27 21:29
I’ve confirmed it is fixed with: https://gerrit.hyperledger.org/r/#/c/4949/

ghaskins
2017-01-27 21:29
ok, cool

muralisr
2017-01-27 21:30
`just wanted to queue a revert so the CI pipeline is primed` … I think thats good to have as a backup and ready regardless of what we do with the current break

garisingh
2017-01-27 21:43
BTW - at some point did the default directory become `/etc/hyperledger/production`

garisingh
2017-01-27 21:44
because now its back to `/var/hyperledger/production`

harrijk
2017-01-27 21:44
Just for grins I performed a git checkout of: commit 2c9826297a9131654a1625bfd49888645d7c748b Author: denyeart <enyeart@us.ibm.com> Date: Mon Jan 23 16:10:47 2017 -0500 The unit-tests run fine. Weird.

garisingh
2017-01-27 21:44
seriously - I just want to run the damn peer :disappointed:

harrijk
2017-01-27 21:45
Perhaps there were some incompatibilities with the original patch and other applied patches.

ghaskins
2017-01-27 21:47
so, the peer container still appears busted in a different way, even after the revert

ghaskins
2017-01-27 21:48

ghaskins
2017-01-27 21:48
not sure what is up yet

garisingh
2017-01-27 21:52
you have to explicitly pass in the MSP config location

muralisr
2017-01-27 21:52
yes… or be in “fabric/“ folder

garisingh
2017-01-27 21:52
but then you fail for other reasons

ghaskins
2017-01-27 21:53
@muralisr this one was you, my friend :wink:

ghaskins
2017-01-27 21:53
036ceec33b

muralisr
2017-01-27 21:53
I know :slightly_smiling_face:

ghaskins
2017-01-27 21:53
heh

ghaskins
2017-01-27 21:53
ok

ghaskins
2017-01-27 21:54
one course of action that seems possibly correct is to add the default to image/peer/Dockerfile.in

muralisr
2017-01-27 21:54
my profound apologies… it was either having all the users do MSPCONFIGPATH or fix it in Dockerfile

ghaskins
2017-01-27 21:54
no worries

ghaskins
2017-01-27 21:55
ill patch locally

muralisr
2017-01-27 21:55
`correct is to add the default to image/peer/Dockerfile.in` is consistent with the fix

ghaskins
2017-01-27 21:55
cool

muralisr
2017-01-27 21:56
do you want me to take care of that ?

muralisr
2017-01-27 21:56
I can...

ghaskins
2017-01-27 21:56
yls pls

muralisr
2017-01-27 21:56
ok

muralisr
2017-01-27 21:56
on it

ghaskins
2017-01-27 21:56
gah, i cannot type today

dave.enyeart
2017-01-27 22:10
the real fix is almost ready… we were iterating through the transactions to write history. worked for ‘normal’ blocks which are used in unit tests… fails for config blocks. fix is to check tran header type:

dave.enyeart
2017-01-27 22:10
if common.HeaderType(payload.Header.ChainHeader.Type) == common.HeaderType_ENDORSER_TRANSACTION

muralisr
2017-01-27 22:17
@ghaskins https://gerrit.hyperledger.org/r/#/c/4953/ fixes the MSPCONFIGPATH for fabric-peer images

ghaskins
2017-01-27 22:23
@muralisr or any other maintainer: +2 this one pls


ghaskins
2017-01-27 22:24
(and submit

ghaskins
2017-01-27 22:24
@ry @ramesh FYI, odd behavior on 4949

ghaskins
2017-01-27 22:24
CI said success but no V+1

ghaskins
2017-01-27 22:24
it manually pushed on out

garisingh
2017-01-27 22:25
@dave.enyeart - was just about to ping the same thing

garisingh
2017-01-27 22:25
can't write config blocks to history (I don't think we want to anyway)

ghaskins
2017-01-27 22:25
ill abandon 4951

ramesh
2017-01-27 22:26
@ghaskins Patch set 2 build is still in progress https://jenkins.hyperledger.org/job/fabric-verify-x86_64/5829/console

dave.enyeart
2017-01-27 22:26
@garisingh agreed. do you want to merge the historyDatabase disablement:

dave.enyeart
2017-01-27 22:26

ghaskins
2017-01-27 22:26
@ramesh ah, ok

ghaskins
2017-01-27 22:26
that explains it

ghaskins
2017-01-27 22:26
ill clear my V+1 then

dave.enyeart
2017-01-27 22:26
while i do some more tests on the ‘real fix'

garisingh
2017-01-27 22:27
@dave.enyeart - can't we just eliminate saving config blocks (well really a block with a single config tx) to history ?

dave.enyeart
2017-01-27 22:28
yes, i’ve got that fix made, just testing it

garisingh
2017-01-27 22:28
that's the "real" fix?

dave.enyeart
2017-01-27 22:28
yes

garisingh
2017-01-27 22:28
ok

garisingh
2017-01-27 22:28
I misunderstood your comment above

dave.enyeart
2017-01-27 22:29
the real fix is to add the condition:

dave.enyeart
2017-01-27 22:29
if common.HeaderType(payload.Header.ChainHeader.Type) == common.HeaderType_ENDORSER_TRANSACTION

dave.enyeart
2017-01-27 22:30
i can push that now, and figure out how to add the unit test with config blocks later

c0rwin
2017-01-27 22:32
@garisingh > can't we just eliminate saving config blocks (well really a block with a single config tx) to history ? is the only block w/ single tx will be a config block?

garisingh
2017-01-27 22:32
no

garisingh
2017-01-27 22:32
I was just clarifying what I meant by config block :wink:

c0rwin
2017-01-27 22:33
Just making sure I’ve got you correctly :blush:

garisingh
2017-01-27 22:33
@dave.enyeart - you should be able to copy the util function which generates a default config block when the peer starts up

garisingh
2017-01-27 22:33
hey - someone has to make sure I am making sense :wink:

garisingh
2017-01-27 22:34
`configtxtest.MakeGenesisBlock(chainID)`

dave.enyeart
2017-01-27 23:11
@garisingh @ghaskins Real fix along with genesis block test pushed: https://gerrit.hyperledger.org/r/#/c/4957/

garisingh
2017-01-27 23:11
will look out for CI to finish

dave.enyeart
2017-01-28 00:27
@garisingh The CI failed, looks like connection problems?

dave.enyeart
2017-01-28 00:28
ah, murali just did reverify

dave.enyeart
2017-01-28 01:59
@ghaskins https://gerrit.hyperledger.org/r/#/c/4957/ passed CI verification, if you want to merge it...

ghaskins
2017-01-28 02:06
done

ghaskins
2017-01-28 02:06
rebased @muralisr fix too

spiro
2017-01-28 03:19
has joined #fabric-dev

karkal72
2017-01-28 17:01
has joined #fabric-dev

arnaud
2017-01-29 12:45
hi there

arnaud
2017-01-29 12:45
I launched a new build (from scratch) with vagrant last night and it failed running the behave tests

arnaud
2017-01-29 12:46
Running behave tests Exception ImportError: No module named sha3 Traceback (most recent call last): File "/usr/local/bin/behave", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python2.7/dist-packages/behave/__main__.py", line 109, in main failed = runner.run() File "/usr/local/lib/python2.7/dist-packages/behave/runner.py", line 672, in run return self.run_with_paths() File "/usr/local/lib/python2.7/dist-packages/behave/runner.py", line 678, in run_with_paths self.load_step_definitions() File "/usr/local/lib/python2.7/dist-packages/behave/runner.py", line 658, in load_step_definitions exec_file(os.path.join(path, name), step_module_globals) File "/usr/local/lib/python2.7/dist-packages/behave/runner.py", line 304, in exec_file exec(code, globals, locals) File "steps/bootstrap_impl.py", line 17, in <module> import endorser_util File "/opt/gopath/src/github.com/hyperledger/fabric/bddtests/steps/endorser_util.py", line 5, in <module> import bootstrap_util File "/opt/gopath/src/github.com/hyperledger/fabric/bddtests/steps/bootstrap_util.py", line 20, in <module> import sha3 ImportError: No module named sha3 Makefile:117: recipe for target 'behave' failed make: *** [behave] Error 1 rm build/image/zookeeper/Dockerfile build/image/testenv/Dockerfile build/image/javaenv/Dockerfile build/image/kafka/Dockerfile build/image/peer/Dockerfile build/image/orderer/Dockerfile build/image/ccenv/Dockerfile

arnaud
2017-01-29 12:47
I've seen this error before and fixing it came down to installing some missing python package

arnaud
2017-01-29 12:47
I'll report back when I get a chance to try that again

ry
2017-01-29 12:52
it looks like `pysha3` is the package

arnaud
2017-01-29 13:17
right

arnaud
2017-01-29 14:40
ok, I got the behave tests running but I had to install 3 python packages: pysh3, pyOpenSSL, and ecdsa

arnaud
2017-01-29 14:40
so, these need to be added to our vagrant environment

muralisr
2017-01-29 14:41
@jeffgarratt had instructions somewhere

muralisr
2017-01-29 14:41
I think in one of the JIRA @arnaud .. let me try look it up

arnaud
2017-01-29 14:42
I'd be happy to submit a CR if I could figure out how to patch this stuff

muralisr
2017-01-29 14:45
@muralisr uploaded a file: https://hyperledgerproject.slack.com/files/muralisr/F3XULBJ9G/pasted_image_at_2017_01_29_09_45_am.png and commented: @arnaud not sure if this is what you are looking for but https://jira.hyperledger.org/browse/FAB-1141 might help

arnaud
2017-01-29 14:45
ok, I'll have a look. Thanks!

muralisr
2017-01-29 14:45
sure!

cybersphaker
2017-01-29 15:19
has joined #fabric-dev

jeffgarratt
2017-01-29 15:47

jeffgarratt
2017-01-29 15:47
I am getting ready to add 1 more dependency as well, will document in that issue

jeffgarratt
2017-01-29 15:48
https://jira.hyperledger.org/browse/FAB-1141 is the running issue I use to document the progress with boostrap, getting ready to add a new change set that goes through the entire process including deployment and verification

arnaud
2017-01-29 15:48
Do you have ecdsa as well?

jeffgarratt
2017-01-29 15:48

jeffgarratt
2017-01-29 15:48
once complete, will make sure that vagrant env changes are in place

arnaud
2017-01-29 15:49
Ok, sounds good

arnaud
2017-01-29 15:49
Thanks

jeffgarratt
2017-01-29 15:49
trying to complete bootstrap in its entirety before CI is re-enabled with behave

jeffgarratt
2017-01-29 15:49
search for 'pip ...'

jeffgarratt
2017-01-29 15:50
the list you determined appears complete

ghaskins
2017-01-29 16:10
@jeffgarratt if you are managing deps for behave, one suggestion I would make is lets get all of the pip stuff into the testenv docker container, and then run behave with $(DRUN) like we do for unit tests

ghaskins
2017-01-29 16:10
then vagrant/native/ci will all work without mods

ghaskins
2017-01-29 16:11
in the near future, I would like to see vagrant/ci be reduced to some minimal environment (e.g. apt-get install make go docker docker-compose)

ghaskins
2017-01-29 16:11
in short, if we need to tweak vagrant, ci, or both, we are doing something wrong

jeffgarratt
2017-01-29 16:14
@ghaskins saw @jyellick attempted a CS to update, but looks like it stalled

ghaskins
2017-01-29 16:14
CS?

jeffgarratt
2017-01-29 16:14
change st

jeffgarratt
2017-01-29 16:14
set

ghaskins
2017-01-29 16:14
ah, roger

jeffgarratt
2017-01-29 16:15
with the above would it still be available from vagrant command line?

jeffgarratt
2017-01-29 16:15
@ghaskins ^

ghaskins
2017-01-29 16:16
you mean to run behave natively in vagrant?

jeffgarratt
2017-01-29 16:16
yes

ghaskins
2017-01-29 16:16
is it unacceptable if it runs in a docker container within vagrant?

jeffgarratt
2017-01-29 16:17
I would prefer to have access from vagrant, as I use it for development

jeffgarratt
2017-01-29 16:17
interactively

jeffgarratt
2017-01-29 16:17
I do not write the behave for CI

jeffgarratt
2017-01-29 16:18
it is just useful as a step up from unit testing

jeffgarratt
2017-01-29 16:18
I use it for development process

ghaskins
2017-01-29 16:18
so, heres where I am coming from: maintaining the vagrant and CI baseimage has become difficult for a variety of uninteresting reasons

ghaskins
2017-01-29 16:18
I see no reason why we couldnt have pip, etc, installed in fabric.git/devenv scripts, rather than baseimage

jeffgarratt
2017-01-29 16:19
k

ghaskins
2017-01-29 16:19
but it should be done in a manner in which devenv and testenv can share

ghaskins
2017-01-29 16:19
if we can achieve that, I think we would both be happy

jeffgarratt
2017-01-29 16:19
understood, would you have some time tomorrow to discuss?

ghaskins
2017-01-29 16:19
e.g. I can drop support for devenv/ci baseimage and vagrant would still support native behave execution

ghaskins
2017-01-29 16:19
sure thing

jeffgarratt
2017-01-29 16:19
thank you!

ghaskins
2017-01-29 16:20
ok, ttyl

dave.enyeart
2017-01-30 11:48
I have created a version of marbles chaincode that demonstrates ledger interaction patterns in v1 -

dave.enyeart
2017-01-30 11:49
It’s called marbles02 to differentiate from the full blown marbles app. And like example02 it can be used for simple trials/demos.

dave.enyeart
2017-01-30 11:50
Demonstrates how to work with JSON in chaincode instead of tables, how to use composite key range queries for simple queries used in transactions, how to structure data for most efficient lookups, how to enable parameterized rich queries vs ad hoc rich queries for point-in-time ledger queries.

dave.enyeart
2017-01-30 11:51
Deploy using `peer chaincode deploy -C myc1 -n marbles -p http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -c '{”Args":["init"]}'`

dave.enyeart
2017-01-30 11:51
Sample invoke and query commands are included as comments at the top of the chaincode

dave.enyeart
2017-01-30 11:52
@jzhang @binhn @weeds @garisingh This can be used as demo at hackathon

dave.enyeart
2017-01-30 11:53
@nickgaski @joshhus Check the comments in the chaincode, there are some nuggets you can use in chaincode authoring documentation

ssaddem
2017-01-30 13:09
has joined #fabric-dev

ssaddem
2017-01-30 13:29
thx

nickgaski
2017-01-30 13:52
@dave.enyeart - that's awesome, thanks. will play around with it today if I have time and see if we can sneak it into alpha. worst case we can at least point to the sample with some pointers on how to do the complex queries

dave.enyeart
2017-01-30 13:53
sure, and its not just the complex queries that are important, at an even more basic its how to use json instead of the old table apis, and how to do simple lookups in chaincode for groups of keys.

vadim
2017-01-30 13:58
by the way, what would be the best way to preserve data stored in the chaincode in case I need to update it?

dave.enyeart
2017-01-30 14:10
any data used across transactions should be stored as state

dave.enyeart
2017-01-30 14:10
via normal PutState() approach

vadim
2017-01-30 14:14
What I mean that if I have a chaincode version 1 that stores data and processes it. Then some business requirements have changed, so I adapted it and now I need to upgrade the existing chaincode. As far as I know, there is no upgrade mechanism for chaincodes, so instead I deploy a new chaincode version 2. But it’s state will be empty, because this is a new chaincode. But logically, it should have the data from the chaincode version 1. So my question is, how to achieve that?

dave.enyeart
2017-01-30 14:28
I believe there are some people thinking about a new upgrade feature that will do just as you say

ghaskins
2017-01-30 14:29
@muralisr ^^^

ghaskins
2017-01-30 14:30
@vadim what you are referring to is generally called "chaincode lifecycle" which includes deployment, upgrade, and termination

ghaskins
2017-01-30 14:31
v0.6 and earlier only supported deployment, but support for upgrade and terminate is emerging (or maybe even available) in master

vadim
2017-01-30 14:32
I’m actually working with master, could you maybe point me out to jira/commit that does it?


vadim
2017-01-30 14:34
thanks a lot

ghaskins
2017-01-30 14:34
yw

claytonsims
2017-01-30 14:37
Taking notes for Binh’s meeting. Plan to cut Alpha today

claytonsims
2017-01-30 14:38
Create a branch

claytonsims
2017-01-30 14:39
the name will be 1.0.0-alpha

claytonsims
2017-01-30 14:41
this is ad hoc meeting in the common area - several developers have gathered

claytonsims
2017-01-30 14:42
tag is 1.0.0-alpha barck v1.0-aplpah

claytonsims
2017-01-30 14:42
branch v1.0-alpha (can’t type)

claytonsims
2017-01-30 14:44
after cut alpha branch - only critical fixes will be added to alpha branch

claytonsims
2017-01-30 14:47
cc calling cc almost done binh working final pieces - shooting to put in alpha

claytonsims
2017-01-30 14:47
bootstrap for channels checked in needs to be merged

claytonsims
2017-01-30 14:50
security and gossip will make call by noon on whether to include in alpah

sagmeister
2017-01-30 14:51
has joined #fabric-dev

claytonsims
2017-01-30 14:53
escc vscc will be post alpha

claytonsims
2017-01-30 14:55
Ledger would like to get one more defect in prior to alpha cut. feature complete for alpha.

claytonsims
2017-01-30 14:57
fabric-ca 4973 required or update doc to workaround

claytonsims
2017-01-30 15:11
murali now talking about cc lifecycle. cc deployed on file system and not on ledger

claytonsims
2017-01-30 15:11
need to work through security aspects

claytonsims
2017-01-30 15:12
have 3 peers, only want 2 peers to have cc, have to install separately on 2 peers

phoolet
2017-01-30 15:26
Hello, i have a problem with fabric v0.6. When i make a post with this json : { "jsonrpc": "2.0", "method": "deploy", "params": { "type": 1, "chaincodeID":{ "name":"mycc" }, "ctorMsg": { "function":"init", "args":["a", "1000", "b", "2000"] }, "secureContext": "lukas" }, "id": "1" } in the json response the status.status is always "OK" . Also when i add some parameters. Why? Thanks

muralisr
2017-01-30 17:58
thanks @claytonsims about deploy / lifecyle changes etc there is a WIP Jira https://jira.hyperledger.org/browse/FAB-1783 and few WIP tasks and gerritt (not for merge)

muralisr
2017-01-30 17:58
hope to put out a video on playback to assist with the review sometime this week

tzipih
2017-01-30 22:23
Hi I am trying to open a specific address from with the system chaincode

tzipih
2017-01-30 22:24
I am running a version based on docker-compose-next-4.yml but am only trying to open one port

tzipih
2017-01-30 22:28
This is the code I am trying to use with the system chaincode:

tzipih
2017-01-30 22:28
// Set up a connection to the server. address := viper.GetString("peer.mpc.serverAddress") logger.Infof("Address read from viper client: %s --------------------------------------------------", address) conn, err := grpc.Dial(address, grpc.WithInsecure()) if err != nil { log.Fatalf("did not connect: %v -----------------------------------------", err) } defer conn.Close() c := mpcclient.NewGreeterClient(conn)

tzipih
2017-01-30 22:29
on the peer I am getting a 'rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure' error

tzipih
2017-01-30 22:29
and similarly on the endorser 'grpc: timed out when dialing'. I wanted to add that when I run it natively (without the docker-compose) this runs correctly and that the client I am using is helloworld from https://github.com/grpc/grpc-go/tree/master/examples

tzipih
2017-01-30 22:30
if anyone can point me to an example that works or perhaps give suggestions?

tzipih
2017-01-30 22:30
Thanks!

hl.rose
2017-01-30 23:23
has joined #fabric-dev

meraki
2017-01-31 10:45
Hello, Trying to deploy marbles02 example. Using code from master branch. Command used: `peer chaincode deploy -C myc1 -n marbles -p http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -c '{"Args":["init"]}'` . Getting this error: Error: Error endorsing chaincode: rpc error: code = 2 desc = Failed to deploy chaincode spec(Error creating image: %!s(<nil>))

meraki
2017-01-31 10:51
Peer logs: ```# http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:303: stub.SplitCompositeKey undefined (type shim.ChaincodeStubInterface has no field or method SplitCompositeKey) src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:395: stub.GetQueryResult undefined (type shim.ChaincodeStubInterface has no field or method GetQueryResult)```

meraki
2017-01-31 10:51
I checked the source code and see that shim package contains 'SplitCompositeKey' function..

vadim
2017-01-31 10:52
which fabric version do you use?

meraki
2017-01-31 10:52
v1.0

meraki
2017-01-31 10:53
Detailed output: ```2017-01-31 10:31:17.470 UTC [dockercontroller] deployImage -> ERRO 3c4 Error building images: The command '/bin/sh -c go install http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 && mv $GOPATH/bin/marbles02 $GOPATH/bin/marbles' returned a non-zero code: 2 2017-01-31 10:31:17.470 UTC [dockercontroller] deployImage -> ERRO 3c5 Image Output: ******************** Step 1/4 : FROM hyperledger/fabric-ccenv:x86_64-0.7.0-snapshot-3ee280e ---> 14e0680b231e Step 2/4 : COPY src $GOPATH/src ---> Using cache ---> 1caabd91b5c4 Step 3/4 : WORKDIR $GOPATH ---> Using cache ---> c4421a348441 Step 4/4 : RUN go install http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 && mv $GOPATH/bin/marbles02 $GOPATH/bin/marbles ---> Running in 748a76679220 # http://github.com/hyperledger/fabric/examples/chaincode/go/marbles02 src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:303: stub.SplitCompositeKey undefined (type shim.ChaincodeStubInterface has no field or method SplitCompositeKey) src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:395: stub.GetQueryResult undefined (type shim.ChaincodeStubInterface has no field or method GetQueryResult)```

meraki
2017-01-31 10:55
Before this I've performed Deploy, Invoke and Query operation on chaincode_example02, it works fine on the same setup.

vadim
2017-01-31 10:55
do you use vagrant?

vadim
2017-01-31 10:56
looks like chaincode tries to build against the old fabric

vadim
2017-01-31 10:56
I've tried on my setup, it worked fine

vadim
2017-01-31 10:57
I use master branch and deployed it in vagrant

meraki
2017-01-31 11:28
I am not using vagrant

meraki
2017-01-31 11:28

meraki
2017-01-31 11:28
And running the deploy command from inside the CLI container

vadim
2017-01-31 11:36
@meraki just guessing here: the setup your mentioned uses some old images which don’t have the recent shim API changes from master, but marbles example needs them

meraki
2017-01-31 11:37
Oh yes. You are probably right.

meraki
2017-01-31 11:40
@vadim what's a easy way to test marbles02 on this setup?

ssaddem
2017-01-31 14:35
there are no rest in v1.0 ?

jonas.hedin
2017-01-31 14:42
has joined #fabric-dev

pd93
2017-01-31 14:44
@ssaddem REST has been deprecated in v1 in favour of GRPC and the SDKs

ssaddem
2017-01-31 15:16
thanks

ratnakar
2017-02-01 00:06
After Vagrant destory & up and then `make native && make docker` is throwing me the error ``` make: *** No rule to make target 'build/bin/orderer', needed by 'orderer'. Stop. vagrant@hyperledger-devenv:v0.2.2-8f5dfca:/opt/gopath/src/github.com/hyperledger/fabric$ make docker make: *** No rule to make target 'build/docker/bin/peer', needed by 'build/image/peer/payload'. Stop. ```

ramesh
2017-02-01 00:28
@ratnakar: can you try on the latest commit.. recently baseimage is upgraded to 0.3.0...

ratnakar
2017-02-01 00:33
Yes it is latest ...And as I said I did Vagrant destroy and vagrant up also ...So I have got the latest base image

ishida_yoshiteru
2017-02-01 02:38
has joined #fabric-dev

passkit
2017-02-01 09:28
I know that it is not one of the official SDK languages, but has anyone built anything in golang for 1.0 that they would be willing to share?

newdev2524
2017-02-01 09:42
I'm using v0.6. Can anyone suggest the method to trace the transaction that it belongs to which user? I saw the cert attribute in transaction but still don't have the idea how we can use it ? (it seems they cannot map with ecert or any tcerts of the user). Thank you in advance for your help.

jansony1
2017-02-01 14:38
has joined #fabric-dev

ghadi
2017-02-01 16:39
has joined #fabric-dev

dave.enyeart
2017-02-01 16:53
@meraki @vadim There is a demo showing how to run marbles02 on latest multi-channel environment: https://youtu.be/XoW9gjAH93k

tzipih
2017-02-01 17:01
Hi I am still trying to solve my port communication issue with docker

yacovm
2017-02-01 17:02
tzipih: what issue?

tzipih
2017-02-01 17:02
I added some details to my January 30 message

tzipih
2017-02-01 17:03
from January 30

tzipih
2017-02-01 17:03
I added some details today

tzipih
2017-02-01 17:03
am trying to open a specific port using an example based on docker-compose-next-4.yml

tzipih
2017-02-01 17:03
with the server from grpc/helloworld example

tzipih
2017-02-01 17:03
can run this successfully without docker

tzipih
2017-02-01 17:04
changed the system chaincode to dial an address

tzipih
2017-02-01 17:04
but from within docker it fails

tzipih
2017-02-01 17:04
but I need to run it inside docker as I am planning eventually to have multiple endorserers/peers

tzipih
2017-02-01 17:05
would appreciate suggestions/examples I can look at. thx

tzipih
2017-02-01 17:05
basically I am trying to open a specific port using an example based off docker-compose-next-4.yml with the grpc/helloworld server

tzipih
2017-02-01 17:06
this runs successfully natively but not within the docker

tzipih
2017-02-01 17:06
would appreciate suggestions. thx

tzipih
2017-02-01 17:07
this is the code I added inside the system chain: / Set up a connection to the server. address := viper.GetString("peer.mpc.serverAddress") logger.Infof("Address read from viper client: %s --------------------------------------------------", address) conn, err := grpc.Dial(address, grpc.WithInsecure()) if err != nil { log.Fatalf("did not connect: %v -----------------------------------------", err) } defer conn.Close() c := mpcclient.NewGreeterClient(conn)

tzipih
2017-02-01 17:07
on the peer I am getting a 'rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure' error

tzipih
2017-02-01 17:07
thanks!

yacovm
2017-02-01 17:19
hmm is the address a hostname or an IP?

yacovm
2017-02-01 17:21
and what's the hostname/ip?

ssaddem
2017-02-01 17:37
please increase the quality of video next time

jflowers
2017-02-01 19:19
has joined #fabric-dev

tzipih
2017-02-01 21:03
Hi sorry I had to go before

tzipih
2017-02-01 21:04
in core.yaml we define:

tzipih
2017-02-01 21:04
mpc: serverAddress: localhost:50051

tzipih
2017-02-01 21:04
so the address is 50051

tzipih
2017-02-01 21:04
we also check and it is indeed the correct address read by viper client

tzipih
2017-02-01 21:04
and it works when running natively but not in docker

tzipih
2017-02-01 21:04
any suggestions?

tzipih
2017-02-01 21:06
@yacovm thanks for looking at this, there should be a way (I assume) to do this from docker, but don't know how

yacovm
2017-02-01 21:20
I'm sorry but i'm no longer on the office, can't take a look now...

yacovm
2017-02-01 21:21
I assume you need to give the right ip address

yacovm
2017-02-01 21:21
Why is this local host?

yacovm
2017-02-01 21:21
Who's trying to xonnect to who?

tzipih
2017-02-01 21:22
כן?

tzipih
2017-02-01 21:23
trying to talk to the helloworld server

tzipih
2017-02-01 21:24
@yacovm יעקב?

yacovm
2017-02-01 21:25
Pms?

tzipih
2017-02-01 21:25
?

ghaskins
2017-02-01 22:50

ghaskins
2017-02-01 22:50
theres the SDK side of FAB-678

ghaskins
2017-02-01 22:51
(its a WIP because it wont work until the fabric side is merged)

ghaskins
2017-02-01 22:51
but it seems to all work fine

viktor.nikolenko
2017-02-01 23:17
has joined #fabric-dev

binhn
2017-02-02 01:17
some folks asking for the CLI I used during my multichannel session ``` All windows below should be in fabric/build/bin Vagrant window 1 - start orderer ORDERER_GENERAL_LOGLEVEL=debug ./orderer Vagrant window 2 - start the peer without **TEST_CHAINID** peer node start --peer-defaultchain=false --logging-level=DEBUG Vagrant window 3 - ask orderer to create a chain peer channel create -c ch1 peer channel join -b ch1.block - deploy a chaincode to myc1 peer chaincode deploy -C ch1 -n cc02 -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}' peer chaincode deploy -C ch2 -n cc04 -p http://github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example04 -c '{"Args":["init","event","1"]}' #note the use of "-C myc1" -- wait for 10 secs or so - query chaincode peer chaincode query -C ch1 -n cc02 -c '{"Args":["query","a"]}' peer chaincode query -C ch2 -n cc04 -c '{"Args":["query","event"]}' peer chaincode query -C ch2 -n cc04 -c '{"Args":["query","event","cc02","a","ch1"]}' - invoke chaincode peer chaincode invoke -C ch1 -n cc02 -c '{"Args":["invoke","a","b","10"]}' peer chaincode invoke -C ch2 -n cc04 -c '{"Args":["invoke","cc02/ch1","event","1"]}’ ```

schwentker
2017-02-02 01:22
has joined #fabric-dev

leminhy89
2017-02-02 03:47
has joined #fabric-dev

coolsvap
2017-02-02 08:27
has joined #fabric-dev

ryokawawork
2017-02-02 11:08
has joined #fabric-dev

meraki
2017-02-02 11:13
Hello, Using v1.0, Vagrant setup. On join channel, getting this error: Error: proposal failed (err: rpc error: code = 2 desc = LedgerID already exists). Command : `peer channel join -b myc1.block`

meraki
2017-02-02 11:14
Running Vagrant setup on windows system.

vadim
2017-02-02 12:36
@meraki have you created a channel? `peer channel create -c myc1`

arnaud
2017-02-02 12:38
is it the second time you're trying this?

ruslan
2017-02-02 12:49
How about checking hash sum of chaincode's source code in an each peer when chaincode is being deploying? Yesterday I had put in a 'peer docker container' different source code files and have used cli to deploy chaincode from local path. As result, fabric has accepted different chaincode

ruslan
2017-02-02 12:53
by same name

vadim
2017-02-02 12:53
@ruslan I guess endorsers’ proposals will be different in this case, so you can discard the wrong proposal from the bad chaincode

ruslan
2017-02-02 12:54
using sdk?

ruslan
2017-02-02 12:55
In my opinion, without pbft sonsensus its a security hole...

vadim
2017-02-02 12:56
this is how it works in v1: you send proposals to peers, they simulate the transaction and sign it (endorse), then you get the results back and the results should be the same

vadim
2017-02-02 12:56
in your case the results won’t be the same

ruslan
2017-02-02 12:56
and next step is to submit this proposals?

vadim
2017-02-02 12:57
yes, to the ordering service

meraki
2017-02-02 12:57
@vadim Yes I have created the channel

vadim
2017-02-02 12:57
I guess it also won’t be happy if they don’t match

vadim
2017-02-02 13:01
@meraki have you tried resetting the chain completely? Removing everything from /var/hyperledger/*, removing myc1.block, then starting orderer and peer again and then creating and joining the channel?

miika
2017-02-02 13:05
has joined #fabric-dev

meraki
2017-02-02 13:15
Will give that a try @vadim

arnaud
2017-02-02 13:18
@meraki, I agree with @vadim, this is likely due to some leftovers from other runs

arnaud
2017-02-02 13:18
that's been my experience at least

muralisr
2017-02-02 14:39
@ghaskins also added @jzhang for https://gerrit.hyperledger.org/r/#/c/5427/

ghaskins
2017-02-02 14:39
@muralisr how did you do that btw?

ghaskins
2017-02-02 14:39
when I try to add reviewers, I fail miserably

ghaskins
2017-02-02 14:40
the only thing I can add is that canned list of the maintainers

muralisr
2017-02-02 14:41
oh really ?


vadim
2017-02-02 14:43
could any of the developers check the issue please? https://jira.hyperledger.org/browse/FAB-1977 . Seems like a bug to me which is easy to fix. Thanks.

muralisr
2017-02-02 14:44
@vadim this needs to be addressed as part of the ACL work for the chaincode … defer to @adc

ghaskins
2017-02-02 14:45
@muralisr i see, others do come up now

ghaskins
2017-02-02 14:45
before they didnt

ghaskins
2017-02-02 14:45
but I cant find you

ghaskins
2017-02-02 14:45
what email are you registered under?

muralisr
2017-02-02 14:45
I added myself …

muralisr
2017-02-02 14:46
but I also use the full name for searching

ghaskins
2017-02-02 14:46
im trying to rope you into this one: https://gerrit.hyperledger.org/r/#/c/5195/

ghaskins
2017-02-02 14:46
:wink:

muralisr
2017-02-02 14:46
it seems to prompt only after typing in the first name fully

ghaskins
2017-02-02 14:46
ah, that could be it

muralisr
2017-02-02 14:46
try “Srinivasan "

ghaskins
2017-02-02 14:46
i need a cheat-sheet for yours :wink:

ghaskins
2017-02-02 14:46
I was putting in "srin" and hoping it would match

ghaskins
2017-02-02 14:46
got it, thx

muralisr
2017-02-02 14:47
sure :slightly_smiling_face:

ghaskins
2017-02-02 14:47
bingo, that worked

ghaskins
2017-02-02 14:47
i didnt think to try the full, I figured if partial match wasnt working, full wasnt going to help

ghaskins
2017-02-02 14:47
but I see how it works now

muralisr
2017-02-02 14:48
right, l think I spent at least 5 mins before landing on the formula :slightly_smiling_face:

ghaskins
2017-02-02 14:48
ty for that

ghaskins
2017-02-02 14:48
i had all but given up on the "add" function

muralisr
2017-02-02 14:48
absolutely :slightly_smiling_face:

muralisr
2017-02-02 14:49
its a feature to make you know the full names of he people you work with :slightly_smiling_face:

ghaskins
2017-02-02 14:49
heh, indeed

ghaskins
2017-02-02 14:50
since you are always "Murali" I was never forced to learn

ashutoshkumar
2017-02-02 14:54
try Murali the gr8, It might work as well.:grinning:

muralisr
2017-02-02 15:00
no worries at all .. and actually Murali is right. Srinivasan is my dad’s name :slightly_smiling_face:

adc
2017-02-02 15:02
@vadim Hi Vadim, there is this change-set that is addressing what you are looking for: https://gerrit.hyperledger.org/r/#/c/5091/

adc
2017-02-02 15:02
Hope that it will be merged soon

vadim
2017-02-02 15:03
@adc thanks, I will close that ticket then

adc
2017-02-02 15:03
thanks for the feedback :slightly_smiling_face:

adc
2017-02-02 15:03
soon we will have back the mechanisms to enforce access control

vadim
2017-02-02 15:04
looking forward to it :slightly_smiling_face:

markparz
2017-02-02 19:57
thanks @sstone1 for showing composer at the hackfest. Here is the deck shown for those that didn’t see it


viktor.nikolenko
2017-02-02 21:09
thanks Mark!

claytonsims
2017-02-02 21:25
We are proposing the following content for an Alpha release. https://wiki.hyperledger.org/projects/proposedv1alphacontent . Take a look and we would like your feedback

claytonsims
2017-02-02 21:26
Let us know what you think!

yacovm
2017-02-02 21:53
claytonsims: kavka-->kafka

claytonsims
2017-02-02 21:53
already done

weeds
2017-02-02 23:30
Also,the following link gives you documentation that provides instructions to get familiar with the preview of the alpha for version 1.0: http://hyperledger-fabric.readthedocs.io/en/latest/gettingstarted/ .In those instructions, it guides you to use Docker Compose that will create a consortium of three organizations, each running an endorsing/committing peer, as well as a “solo” orderer and a Certificate Authority (CA). The network will be generated automatically upon execution of docker-compose up, and the APIs for create channel and join channel will be explained and demonstrated; as such, a user can go through the steps to manually generate their own network and channel, or quickly jump to the application development phase.

jonathanbmorley
2017-02-02 23:34
Thanks, @weeds!

weeds
2017-02-02 23:41
hi everybody, in case you have not heard, linux foundation is moving us off of Slack and onto Rocket.Chat, everybody in Slack can log in to the new chat server using your existing linux foundation ID, please visit http://chat.hyperledger.org/ to login to the new chat server

jimyang
2017-02-03 02:45
has joined #fabric-dev

john.d.sheehan
2017-02-03 14:47
Hi, could somebody help me with the following error? *vp_18_00009_1 | 11:59:21.111 [peer] handleChat -> ERRO 03d Error handling message: Peer FSM cannot handle message (DISC_GET_PEERS) with payload size (0) while in state: created* *vp_18_00013_1 | 11:59:21.217 [peer] ensureConnected -> WARN 040 Touch service indicates dropped connections, attempting to reconnect…* I am using the following images *ibmblockchain/fabric-peer:ppc64le-0.6.1-preview* and *hyperledger/fabric-baseimage:ppc64le-0.2.2* and I get the errors if I try and start 17 or more peers with docker-compose. Could it be a docker issue?

muralisr
2017-02-03 15:04
@john.d.sheehan the error is from the discovery/pings between peers …hard to say for sure, but I would doubt its a docker issue. First guess would be gRPC dropping connection

john.d.sheehan
2017-02-03 15:08
Thanks @muralisr, is there any way to work around the issue or diagnose the cause? Is there an upper bound on the number of peers in v0.6?

muralisr
2017-02-03 15:11
I do not know of work around (honestly, I have’t tried with more than 4 peers). It does say `attempting to reconnect` .. did that work ?

muralisr
2017-02-03 15:13
as to upperbounds, are you using pbft or noops ? if pbft, I’d check on fabric-consensensus-dev as a first cut upperbound for pbft

john.d.sheehan
2017-02-03 15:15
@muralisr it is using pbft

john.d.sheehan
2017-02-03 15:15
I’ll try it with noops, that should rule out pbft?

muralisr
2017-02-03 15:16
it would, yes

john.d.sheehan
2017-02-03 15:21
No, switching to noops has no effect *vp_18_00006_1 | 15:16:31.471 [rest] StartOpenchainRESTServer -> INFO 018 Initializing the REST service on 0.0.0.0:7050, TLS is disabled.* *vp_18_00017_1 | 15:16:34.482 [peer] handleChat -> ERRO 019 Error handling message: Peer FSM failed while handling message (DISC_HELLO): current state: created, error: transition canceled with error: Error registering Handler: Duplicate Handler error: {name:"vp_18_00001" 172.18.0.16:7051 VALIDATOR }* *vp_18_00001_1 | 15:16:34.483 [peer] handleChat -> ERRO 019 Error handling message: Peer FSM failed while handling message (DISC_HELLO): current state: created, error: transition canceled with error: Error registering Handler: Duplicate Handler error: {name:"vp_18_00017" 172.18.0.11:7051 VALIDATOR }*

gbolo
2017-02-03 15:49
has joined #fabric-dev

gbolo
2017-02-03 15:49
I am getting a panic when running peer: panic: ---empty version---(chain=,chaincode=cscc,version=,txid=26d72afe-e3d9-4314-b1cb-53aeff0d3271,syscc=true,proposal=0x0

gbolo
2017-02-03 15:49
what is this empty version all about?

vadim
2017-02-03 16:18
@gbolo I suppose you need to rebuild the peer, i.e. do `make peer`in the fabric directory

muralisr
2017-02-03 16:21
@gbolo second @vadim’s recommendatiod. The above is what I’d expect if you did “go build” and “./peer” … but basically the fabrics version is not being set in the exe

gbolo
2017-02-03 16:21
@vadim yea i found that i needed -ldflags "-X http://github.com/hyperledger/fabric/common/metadata.Version=1.0.0-preview" during my go build

muralisr
2017-02-03 16:21
right

muralisr
2017-02-03 16:21
or that

muralisr
2017-02-03 16:22
`make peer` does the ldflags glue for you

gbolo
2017-02-03 16:22
yea i just noticed :slightly_smiling_face:

muralisr
2017-02-03 16:22
:slightly_smiling_face:

gbolo
2017-02-03 16:22
sorry about that

muralisr
2017-02-03 16:22
no worries

gbolo
2017-02-03 16:22
things change really fast

muralisr
2017-02-03 16:22
that they do

gbolo
2017-02-03 16:23
another hard time im having is this msp config certs and the orderer.template

gbolo
2017-02-03 16:24
any ideas on this? how to generate these?

silliman
2017-02-03 16:46
@john.d.sheehan Often, the cause of what you are seeing is as follows: I've seen this where people are trying to use the v0.6 branch of the code and then are following the instructions in the v0.6 branch of the documentation, but....get twisted up because there are a couple spots in this doc where it has a wget (for the chaincode) and a git clone (for getting the fabric code available locally in order to build the chaincode) that refer to *master*. The problem is, that *master* is now v1.0 code. So, they are running Docker images with v0.6 code but when they build the chaincode locally, it incorporates v1.0 code in into it. The solution is, in the *wget* and the *git clone*, change *master* to *v0.6* in the path name. I am being purposely vague as to where this documentation is, because if I've guessed correctly, you know what I'm referring to, but if I've guessed wrong, it's something else and I don't want to lead you on a wild goose chase. I hope this helps.

john.d.sheehan
2017-02-03 16:58
Hi @silliman, tbh, I followed bits and pieces of various docs. What I did was ``` docker pull ibmblockchain/fabric-peer:ppc64le-0.6.1-preview docker pull hyperledger/fabric-baseimage:ppc64le-0.2.2 docker tag ibmblockchain/fabric-peer:ppc64le-0.6.1-preview hyperledger/fabric-peer:latest docker tag hyperledger/fabric-baseimage:ppc64le-0.2.2 hyperledger/fabric-baseimage:latest ``` created a *peer.yml* ``` version: '2' services: vp: image: hyperledger/fabric-peer:latest restart: unless-stopped environment: - CORE_PEER_ADDRESSAUTODETECT=true - CORE_PEER_NETWORKID=dev - CORE_LOGGING_LEVEL=info #critical, error, warning, notice, info, debug # The following section enables pbft consensus - CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=noops # noops, pbft - CORE_PBFT_GENERAL_MODE=batch # batch. classic and sieve will be not supported again. - CORE_PBFT_GENERAL_N=4 - CORE_PBFT_GENERAL_BATCHSIZE=2 # only useful when in batch mode - CORE_PBFT_GENERAL_TIMEOUT_REQUEST=2s - GOPATH=/opt/gopath expose: - "7050" # Rest - "7051" # Grpc - "7052" # Peer CLI - "7053" # Peer Event - "7054" # eCAP - "7055" # eCAA - "7056" # tCAP - "7057" # eCAA - "7058" # tlsCAP - "7059" # tlsCAA volumes: # docker.sock is mapped as the default CORE_VM_ENDPOINT - /home/sheehanj/quickstart/chaincode:/opt/gopath/src/chaincode - /var/run/docker.sock:/var/run/docker.sock command: peer node start ``` created *00018peers.yml* ``` version: '2' services: # validating node as the root # vp0 will also be used for client interactive operations # If you want to run fabric command on the host, then map 7051:7051 to host # port, or use like `CORE_PEER_ADDRESS=172.17.0.2:7051` to specify peer addr. vp_18_00000: extends: file: peer.yml service: vp hostname: vp_18_00000 environment: - CORE_PEER_ID=vp_18_00000 ports: - "7050:7050" #- "7051:7051" # validating node vp_18_00001: extends: file: peer.yml service: vp hostname: vp_18_00001 environment: - CORE_PEER_ID=vp_18_00001 - CORE_PEER_DISCOVERY_ROOTNODE=vp_18_00000:7051 links: - vp_18_00000 # validating node vp_18_00002: extends: file: peer.yml service: vp hostname: vp_18_00002 environment: - CORE_PEER_ID=vp_18_00002 - CORE_PEER_DISCOVERY_ROOTNODE=vp_18_00000:7051 links: - vp_18_00000 etc... ``` and ran *docker-compose -f 00018peers.yml up*

silliman
2017-02-03 17:01
@john.d.sheehan what I described is only applicable if you are getting it when trying to do a query- that is, you have successfully deployed and invoked the chaincode_example02. Also, I should have mentioned this, I was referring to your original error message that mentioned *Peer FSM...* If that error occurred anywhere else you are probably running into something different. You're already off the beaten path by running on Power (not that there's anything wrong with that!)

john.d.sheehan
2017-02-03 17:05
@silliman :smile: . have you tried running lots (more than 16 say) peers (on any arch)?

silliman
2017-02-03 17:06
@john.d.sheehan I'm lazy. I've maxed out at 4.

john.d.sheehan
2017-02-03 17:08
@silliman no worries, I thought I ask.

jonathanlevi
2017-02-03 18:38

mohamoudegal
2017-02-05 21:42
which version of cURL do I need to run Fabric on Mac OS?

newdev2524
2017-02-06 08:23
Hi, I'm using v0.6 with TLS enabled. after I enabled TLS, it seems I cannot access to PEER node via REST anymore although I installed the certificate on the browser. Is this the normal behavior? Could anyone suggest on this? Thanks

rocket.chat
2017-02-06 16:11
has joined #fabric-dev

kenzhang
2017-02-06 20:41
got question about production env for fabric. would container be supported or it's just for development?

jonathanlevi
2017-02-06 21:28
@ry: nice!

ry
2017-02-06 21:28
@jonathanlevi it's a one-way mirror

jonathanlevi
2017-02-06 21:28
Like a one-way hash, all the way! :wink:

tzipih
2017-02-06 23:43
Hi I need some help. I am working with fabric 1.0.

tzipih
2017-02-06 23:44
I am trying to specify ore than one endorser for the blockchain

tzipih
2017-02-06 23:45
the endorsement-policies document specifies using -P and then the endorsers

tzipih
2017-02-06 23:46
but when I am trying to send a simliar deploy command, I am getting an error that -P is an unknown flag

tzipih
2017-02-06 23:47
I looked in the next-consensus-architecture-proposal but did not find an updated method to specify this

tzipih
2017-02-06 23:47
Could anyone suggest what the updated command is for two endorserers?

mohamoudegal
2017-02-07 04:46
Hi,

mohamoudegal
2017-02-07 04:48
I am working to on a Chaincode tutorial and I’m currently stuck. Below is a screen shot of the error message, my file directory for the example Chain code go file I made per instructions and the command I was supposed to use


jonathanlevi
2017-02-07 04:48
I highly recommend https://chat.hyperledger.org...

mohamoudegal
2017-02-07 04:54
@jonathanlevi thanks

ry
2017-02-07 17:57
@ry archived the channel (w/ 465 members)